**** BEGIN LOGGING AT Thu Sep 12 02:59:59 2013 Sep 12 04:25:42 good morning, i am trying to change the name of the actual .ipk or .deb or .rpm file that bitbake will create, for now i was playing around with the PF PV PR and P variable in the bitbake.conf but for some reason bitbake will always add a PR_plattform.ipk (qemux86 or others) to the file name, is there a better way to do this or a way that is more correct ? Sep 12 06:20:54 good morning, i am trying to change the naming of the packages (something.ipk) that bitbake produces in the deploy/ipk/* dir ... where do i do this ... i cannot find anything in the yocto manual Sep 12 06:46:35 hi, were can i change the naming of the binary pkg or how is the binary pkg named ? Sep 12 07:08:19 hi, were can i change the naming of the binary pkg or how is the binary pkg named ? Sep 12 07:24:30 is there a meta-linaro layer working in yocto? I'm having a lot of trouble using the layer for oe Sep 12 07:37:12 good morning Sep 12 07:50:12 good morning mckoan Sep 12 07:51:03 bluelightning is were dose yocto name the binary packages Sep 12 07:51:18 morning all Sep 12 07:51:32 good morning Sep 12 07:51:40 wfailla: what's the context? Sep 12 07:52:42 bluelightning i am trying to change the naming from PN_PV-PR.ipk to PN_PV-PR-SRCREV.ipk when the pr-serv is used Sep 12 07:53:33 wfailla: you're not happy with the results of PV = "1.0+git${SRCPV}" or similar? Sep 12 07:54:17 bluelightning no because i want that to happen automatically Sep 12 07:54:48 bluelightning only when the SRCREV is set to ${AUOTREV} Sep 12 07:56:26 bluelightning the way i do it for now is PV-orig := "${PV}" PV := "${PV-orig}-${PR}-${SRCPV}" Sep 12 07:58:36 bluelightning but the pkg is then called PN_PV-PR-SRCPV-PR_mips32.ipk but i cant figure out why there is a PR in there again Sep 12 07:59:04 wfailla: assuming you're trying to cover bleeding-edge development and release versions, typically the way people handle that is to use separate recipes for the two cases (perhaps with a common inc file to avoid duplication) Sep 12 07:59:12 bluelightning and were the platform comes from Sep 12 07:59:38 wfailla: you're getting PR twice because PR isn't normally part of PV, and you're adding it Sep 12 07:59:51 wfailla: the platform comes from PACKAGE_ARCH Sep 12 08:01:07 bluelightning but if i have a pkg named opencapwap-1.1.4 and opencapwap-1.1.5 they should not be installed along side Sep 12 08:01:25 bluelightning how do i stop this from happening Sep 12 08:01:35 wfailla: no, they can't; but if that's what you need then you need to be changing PN Sep 12 08:02:04 i.e. making PN version-specific Sep 12 08:03:53 bluelightning stop no i cant fallow u any more ... if the pn is opencapwap-1.1.4 and the pv is 1.1.4 and there is a pkg with the pn opencapwap-1.1.5 with the pv 1.1.5 what stops them from bolth being installed on the same system Sep 12 08:06:34 wfailla: most package managers do not allow two packages with the same name to be installed at the same time (although some allow it if the architecture is different) Sep 12 08:06:50 wfailla: and we rely on the package manager for rootfs construction Sep 12 08:07:16 bluelightning but the name is not the same the one is opencapwap-1.1.4 and the other is opencapwap-1.1.5 Sep 12 08:07:47 wfailla: right, if you have changed PN to be version-specific then that gets around that issue Sep 12 08:08:04 wfailla: of course, if the packages install any of the same files you'll also have issues Sep 12 08:08:33 since most package managers will not allow you to install two packages that install the same file unless you force them to Sep 12 08:09:58 bluelightning change the pn to be version specific were ?? in the recipe ? Sep 12 08:10:17 bluelightning of opencapwap? Sep 12 08:10:28 wfailla: you can either set PN in the recipe or you can just rename the recipe since PN is derived from the recipe file name Sep 12 08:11:01 (by default) Sep 12 08:12:27 bluelightning yes but still there will be two pkg opencapwap-1.1.4 and opencapwap-1.1.5 which can be run together on the same machine , but i dont want that to be possibile Sep 12 08:13:14 wfailla: ah, sorry I got confused, I thought that's what you were asking to be able to do Sep 12 08:13:38 let's start again Sep 12 08:14:16 ok ... give me a sec Sep 12 08:15:16 the versioning as it is works fine for me, i have a opencapwap_1.1.4.bb a opencapwap_1.1.5.bb and a opencapwap_1.1.6.bb Sep 12 08:15:38 i can chose one by stating the preferred version Sep 12 08:16:03 right Sep 12 08:16:10 the bin pkg will be named pn_PV-PR_mips.ipk Sep 12 08:17:08 but there should also be a opencapwap_git.bb witch has the SRCREV= "${AUTOREV}" Sep 12 08:17:24 right, and there can be Sep 12 08:17:59 and if that recipe sets PV = "x.y+git${SRCPV}" you'll have the revision in the recipe but only for that recipe, not the others Sep 12 08:18:09 and the bin pkg created when bitbaking that recipe should be named PN_PV-PR-SRCREV_mips.ipk automatically Sep 12 08:18:54 is it possible to rename that automatically Sep 12 08:19:05 ? Sep 12 08:22:04 wfailla: just so I understand, why is that better than PN_x.y+git1+SRCREV_PR_mips32.ipk ? Sep 12 08:22:18 (which is what setting PV as above will result in) Sep 12 08:22:24 and an other thing i had an problem with is that if i change the PV value then i cannot use FILESEXTRAPATH_prepend = "${THISDIR}/${PN}-${PV}" for .bbappends or so ... but this is an other problem Sep 12 08:23:30 right, you'd need to do something more complicated if you really need the files directory to be version-specific (or just hardcode it) Sep 12 08:23:46 because for what i do i need the PR in front of the git tag Sep 12 08:24:34 what i would do is create a PV-orig = ${PV} and then use FILESEXTRAPATH_prepend = "${THISDIR}/${PN}-${PV-orig}" Sep 12 08:25:16 I guess I don't quite understand your use case Sep 12 08:25:50 no use case just readability Sep 12 08:26:15 i thought it would be easy to change that Sep 12 08:28:58 but my second problem has a use case i have a destro which has a packagegroup-lng-1.1 installed with a specific versions of pkg installed Sep 12 08:29:17 i am using ipk Sep 12 08:30:06 how do i set a specific version just for that pkg group not for other builds i make with the same build dir Sep 12 08:30:50 and i cant use the pn for version control because of what we were talking about before Sep 12 08:31:35 I don't think you can do it without changing PN Sep 12 08:32:08 you can explicitly make the two conflict by setting RCONFLICTS to prevent side-by-side installation Sep 12 08:32:35 that might be an option Sep 12 08:33:57 can i set some thing like RCONFILCTS = "opencapwap-1.1.*" or RCONFILCTS = "opencapwap-1.1.[1..4]" Sep 12 08:35:47 wfailla: I don't think so, unless opkg understands that (since we just pass that to opkg when ipk is being used) Sep 12 08:43:11 opkg is supposed to understand regular expressions Sep 12 08:48:27 hi all Sep 12 08:48:49 hi Sep 12 08:49:16 I'm trying to build chromium from meta-browser (just updated to v 31 and update ninja + nss to latest versions) but during linking I get ng.a: could not read symbols: Memory exhausted Sep 12 08:49:38 any ideas how to resolve that (I have 32bit ubuntu) Sep 12 08:52:57 mbelisko: I'm not sure but this sounds like the problem I've heard reported building webkit Sep 12 08:53:45 mbelisko: webkit / chrome is such a huge codebase that if you set high parallelism (BB_NUMBER_THREADS / PARALLEL_MAKE) it seems like you can run out of memory Sep 12 08:53:56 bluelightning: obj/third_party/WebKit/Source/core/libwebcore_remaining.a: could not read symbols: Memory exhausted Sep 12 08:54:15 bluelightning: I have both on 4 Sep 12 08:55:04 bluelightning: should I try without parallelism? Sep 12 08:55:05 mbelisko: FWIW, here is the webkit bug report: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5160 Sep 12 08:55:05 Bug 5160: normal, Undecided, ---, laurentiu.palcu, NEW , webkit-gtk build failed randomly with "Memory exhausted" Sep 12 08:56:28 bluelightning: i don't think its parallism, its just the final link Sep 12 08:57:05 mbelisko: add LDFLAGS += " -Wl,--no-keep-memory" to webkit-gtk.bb Sep 12 08:57:57 rburton: ok lemme try Sep 12 09:00:32 Hi, im trying to build yocto with a custom kernel version by adding the lines PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" and PREFERRED_VERSION_linux-yocto= "3.2" in local.conf, but it still uses 3.8, am i doing it wrong? Sep 12 09:10:47 BjornArnelid: I'd recommend checking to see if those are being overridden somewhere Sep 12 09:11:29 BjornArnelid: use bitbake -e | less and search for PREFERRED_VERSION_linux-yocto Sep 12 09:13:32 rburton: ok memory exhausted is over but during chromium linking I got: collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped Sep 12 09:14:00 oh wait ld: cannot size stub section: Memory exhausted Sep 12 09:14:25 added -Wl,--no-keep-memory to LDFLAGS for chromium Sep 12 09:55:38 mbelisko: is your build host 32 or 64 bit, and how much ram? Sep 12 09:58:47 rburton: 32bit 8G ram Sep 12 09:58:58 impressive that it fills it up :) Sep 12 09:59:05 ah, but Sep 12 09:59:20 per-process limit is a lot lower Sep 12 09:59:31 if you can reboot in 64-bit i bet it will work without the option Sep 12 10:00:30 rburton: maybe ulimit would help? Sep 12 10:01:14 Well, 32bit system can only use up to 3 gigs of ram at most, per process Sep 12 10:01:19 well not: ulimit->unlimited Sep 12 10:01:31 ok Sep 12 10:01:40 mbelisko: what Kaapeli said Sep 12 10:01:57 That's why you don't use 32bit kernels if you have more than 3 gigs or ram Sep 12 10:02:13 Kaapeli: *generally* the 3G limit isn't a massive problem though Sep 12 10:02:27 rburton, Usually no Sep 12 10:02:55 But it can beat you in strange ways if you expect to be able to use a lot of memory on 32 bit systems Sep 12 10:03:07 indeed Sep 12 10:03:29 maybe we should make webkit throw a note if the host is 32-bit Sep 12 10:03:45 well this is chromium internal webkit Sep 12 10:04:29 I'm trying to update chromium to v31 (in meta-browser is v29) Sep 12 10:04:42 ok seem I need to use 64 bit Sep 12 10:04:49 thanks for your help Sep 12 10:05:15 rburton: On the oe mailing list regarding bb-matrix, you suggested using bitbake -e to find which temporary directories to remove (mentioning wipe-sysroot). I have not been able to find anything anywhere when looking for wipe-sysroot (or wipe for that matter). Any suggestions? Sep 12 10:06:10 Saur: oe-core/scripts/wipe-sysroot Sep 12 10:06:56 rburton: Duh, no wonder grep didn't find anything. :) Sep 12 12:12:09 dose anybody use arch as linux host ? Sep 12 12:12:40 qt-x: good luck with that :((( Sep 12 12:13:19 so no good news in that direction? Sep 12 12:13:24 I'm using lxc just to use yocto on my arch Sep 12 12:15:43 n01: is it a difficult setup process ? Sep 12 12:16:59 not at all https://wiki.archlinux.org/index.php/Linux_Containers Sep 12 12:17:26 even better http://andyortlieb.wordpress.com/2013/03/15/practical-use-of-lxc-in-arch-linux-in-march-of-2013/ Sep 12 12:18:29 sorry I was not very clear. I was referring to yocto not lxc Sep 12 12:19:37 well, there's a lot of documentation for yocto Sep 12 12:22:02 my recommendation run bitbake and install the missing depends when bitbake tells u to an the fly Sep 12 12:22:48 then delete the build directory and u can start Sep 12 12:24:53 I have a question this is the line in the recipe SRC_URI = "git:///usr/src/disk/wfailla/test-git.git;protocol=file" the local git repo is /usr/src/disk/wfailla/test-git.git/. why cant bitbake find the repo ? Sep 12 12:26:38 i initialized the repo by executing "git init" in the /usr/src/disk/wfailla/test-git.git/. dir Sep 12 12:28:05 wfailla: just a stab in the dark, it's not being confused by the directory being named .git is it? Sep 12 12:28:18 *.git that is Sep 12 12:28:42 i hope not ;-) Sep 12 12:29:42 no ... thats not it Sep 12 12:30:39 ERROR: Error executing a python function in : | ETA: 00:00:20 Sep 12 12:30:39 ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception MalformedUrl: The URL: 'git:/usr/ Sep 12 12:30:39 src/disk/wfailla/test-git.git' is invalid and cannot be interpreted Sep 12 12:34:33 hmm Sep 12 12:34:39 I was about to say I just tried that and it worked... Sep 12 12:54:51 I'm trying to follow along with the ADT manual and get the following when installing the prerequisites on Fedora 19: No package eglibc-devel available. Is it a typo or just a missing package for that distro version? Sep 12 12:55:13 i also tried with eglibc-dev Sep 12 13:22:41 someone seeing apr-util-native builds failing with dash as shell? x86_64-linux-libtool: preserve_args+= --silent: not found Sep 12 13:23:53 sometimes the error looks a bit different, I've reported it half year ago when apr-util was upgraded: http://lists.openembedded.org/pipermail/openembedded-core/2013-March/076087.html Sep 12 13:32:55 ok, there are still some bashisms in libtool script, I'll fill bug about it Sep 12 13:52:15 when are you going to update the yocto eclipse plugin video? It doesn't look anything like the existing preferences page. Sep 12 13:53:04 cfo215, btw, looks like f19 is back to glibc not eglibc Sep 12 13:54:10 hmm, so are odler fedoras must be a type Sep 12 13:59:55 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5174 Sep 12 13:59:56 Bug 5174: normal, Undecided, ---, laurentiu.palcu, NEW , libtool with bashisms enabled in script can be shared through sstate-cache with host where /bin/sh is dash and cause build issues Sep 12 14:02:29 cfo215: here are some Yocto eclipse videos :) http://www.youtube.com/watch?v=i6KaMrhVOw8 Sep 12 14:03:00 maxin, thanks! Sep 12 14:30:58 bluelightning: ping Sep 12 14:32:46 bluelightning: I have small question about buildhistory srcrev tracking code, currently we have: Sep 12 14:32:49 with open(srcrevfile, 'w') as f: Sep 12 14:32:52 orig_srcrev = d.getVar('SRCREV', False) or 'INVALID' Sep 12 14:33:47 The False is there probably to keep AUTOINC I guess, but it's unfortunate when SRCREV is set through some other variable (e.g. SRCREV = "${SRCREV-FOO}" in recipe Sep 12 14:34:39 shouldn't need that False anymore now that autoinc is a string rather than a variable reference, eh? Sep 12 14:34:44 * kergoth yawns, morning Sep 12 14:36:02 I can try later if bluelightning agrees Sep 12 14:41:22 and slightly unrelated topic, it would be great to add few parameters to scripts/buildhistory-diff allowing to specify which changes are considered to be significant Sep 12 14:42:53 e.g. when I was trying to detect file permissions changing randomly because of pseudo I always had to filter PV/PKGR/PKGV changes which made 90% of the diff Sep 12 14:56:14 huum where does linux-yocto-tiny_3.8 take its defconfig? Sep 12 15:01:03 rburton: we need to change SRC_URI in renderer-service-upnp, media-service-upnp so something more stable than archives generated on-demand on github, both have different checksums now Sep 12 15:01:20 urgh Sep 12 15:01:22 noted Sep 12 15:01:23 rburton: are you still interested in them (as you've added them)? Sep 12 15:01:33 JaMa: i've a todo about upgrading the versions Sep 12 15:01:43 as i said i'd sort-of-maintain them Sep 12 15:01:56 hopefully they've got proper tarballs too Sep 12 15:06:08 rburton: ok, fair enough, thanks Sep 12 15:08:11 damn, no proper tarballs for the old releases. Sep 12 15:08:48 I really hate when people re-roll their tarballs :/ Sep 12 15:09:24 bluelightning: the current recipes point at github's magic tarball URL Sep 12 15:13:27 rburton: I see, I guess that can't ever be expected to work... Sep 12 15:13:58 bluelightning: yeah, my fault. should have just made git recipes. Sep 12 15:14:30 you'd think github would cache the archives, but there's no telling what their cache policy is :) Sep 12 15:15:14 yes it always works for some time, long enough to pass verification builds and populate most PREMIRRORs Sep 12 15:15:32 until a lot later when I try to build world on fresh host or delete downloads directory Sep 12 15:17:02 RP: check this out.. we have a class that does a sstate_create_package_append to call another function we define. on our 64 bit jenkins vms, for omap5-evm, we get an error that our function isn't defined, as though bitbake didn't pick up the variable dependency.. yet it doesn't happen anywhere else, and it doesn't happen for every recipe. weird eh? Sep 12 15:17:03 * kergoth digs Sep 12 15:17:05 kergoth: this is an old revision of a not massively popular package, you can imagine it got purged Sep 12 15:17:14 * kergoth nods Sep 12 15:17:18 changing to use git clones now Sep 12 15:21:11 hmm, should create a bb subcommand to show the variable dependencies bitbake picked up, directly to the user, rather than just having the ability to show a variable and its deps Sep 12 15:30:21 kergoth: that does sound odd :/ Sep 12 15:35:45 Hmm I have a weird issue. I have a recipe for a script I've written, and it fetches the script source from git. However, it does not seem to be enough to simply update SRCREV and rebuild the script, I have to either cleanall or update the revision count... any clues as to why this would be? It has happened a few times now, that for this particular package, I've updated SRC_REV and then build an image (the daemon is in conf/local.c Sep 12 15:35:45 onf), only to then see it was the older version. Sep 12 15:38:05 I would think that updating the recipe should trigger a rerun of the recipe, and it does seem to build and such again... just using version of the files from an older commit. Sep 12 15:39:05 is SRCPV in your PV? Sep 12 15:41:08 kergoth, No, it is not, I just have 'SRCREV = "..."' in the recipe. Sep 12 15:41:34 It's sorta lazy but I've been using daemon_1.0.bb forever (Since we have not released quite yet this is not an evil horrible thing). Sep 12 16:37:46 moin Sep 12 17:15:27 rburton: there is another advantage of using git clones in this case.. "v0.3.0.zip" isn't very unique filename for downloads folder :) Sep 12 17:16:21 true :) Sep 12 17:21:41 heh and it's quite bigger with the same content Sep 12 17:21:42 -rw-r--r-- 1 mjansa mjansa 81845 Sep 12 10:17 v0.3.0.zip Sep 12 17:21:42 -rw-rw-r-- 1 mjansa mjansa 82691 Sep 12 08:30 v0.3.0.zip_bad-checksum_d728337c14456b17606b436eb82ce6b7 Sep 12 17:22:25 -rw-r--r-- 1 mjansa mjansa 130073 Sep 12 10:17 v0.4.0.zip Sep 12 17:22:25 -rw-r--r-- 1 mjansa mjansa 131225 Sep 12 10:17 v0.4.0.zip_bad-checksum_deb04e63353dd29ddef3308138cb4ee5 Sep 12 17:41:56 JaMa: ping Sep 12 17:43:17 pong Sep 12 17:43:41 JaMa: Hi - I have some questions for you if you have time on the BSP layer issue. Sep 12 17:43:42 do those examples help at least a bit? Sep 12 17:44:13 JaMa: I am going private so not to get to windy on the channel Sep 12 19:22:27 I think I might be close to having a working qt5 nativesdk. The problem is qmake isn't getting relocated correctly. I used the qmake from ${STAGING_BINDIR_NATIVE}/${QT_DIR_NAME}/qmake. Here is the error when I run qmake and the output of ldd on qmake and moc which works, http://pastebin.com/LKecSwc5. How can I solve this issue? Sep 12 20:47:02 i just love it when i can't use bitbake -S due to one of ERROR: Bitbake's cached basehash does not match the one we just generated Sep 12 20:47:08 * kergoth rolls eyes Sep 12 20:53:51 kergoth: how is it kergoth world? Sep 12 20:53:54 *in Sep 12 20:54:08 challinan: going to ELCE? can't recall Sep 12 20:54:40 mranostay: on phone, but answer is yes :-) Sep 12 20:55:28 kergoth: it shows it, but still produces the .sigdata files OK, doesn't it? Sep 12 20:56:39 kergoth: some cases where the basehash was e.g. depending on DATETIME were fixed, but e.g. perf is still changing signature while running -S Sep 12 21:00:15 ah, yes, indeed, thanks Sep 12 21:04:43 JaMa: I am looking at that libtool bug, was hoping for a way to force it to not use bash, but seems to be harder than I thought! Sep 12 21:05:04 JaMa: bug #5174 Sep 12 21:05:05 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=5174 normal, Medium, 1.5 M5, saul.wold, NEW , libtool with bashisms enabled in script can be shared through sstate-cache with host where /bin/sh is dash and cause build issues Sep 12 21:08:37 sgw_: agreed, it's a bit weird, I've tried to compare libtool scripts from multiple hosts with different shell settings Sep 12 21:09:01 sgw_: as SHELL=/bin/bash or /bin/sh and then /bin/sh -> /bin/bash or /bin/dash Sep 12 21:09:18 and these += are in all combinations I was able to generate Sep 12 21:10:12 Jama, yeah, I also looked at those debian bugs and they seem to imply it should be using #!/usr/bin/bash but it's clearly doing /usr/bin/sh Sep 12 21:10:38 sometimes it is using bash shebang (e.g. on my machine it does) Sep 12 21:10:47 I tried forcing it with CONFIG_SHELL, but that seems to cause other failures Sep 12 21:10:52 but that's where I have it set in SHELL env Sep 12 21:11:55 and there are some more differences between libtools from different hosts, e.g. sys_lib_dlsearch_path_spec sometimes has /usr/lib/x86_64-linux-gnu/mesa Sep 12 21:12:02 etc Sep 12 21:12:12 < max_cmd_len=1572864 Sep 12 21:12:13 --- Sep 12 21:12:13 > max_cmd_len=3458764513820540925 Sep 12 21:12:14 jama, what I saw happening is it still gets set to sh even with SHELL=bash in the run.do_configure Sep 12 21:13:27 this is diff between my host and some other jenkins slave http://bpaste.net/show/131918/ Sep 12 21:17:10 JaMa: different compilers on the two machines also it looks like. I am amazed we have not uncovered this before. Sep 12 21:18:41 sgw_: in this case it wouldn't reuse libtool from sstate-cache because of different lsb-release string for host Sep 12 21:19:11 sgw_: I've used it only because I had access to older ubuntu slave with dash Sep 12 21:19:29 sgw_: the other one (with bash) is from my local gentoo chroot env Sep 12 21:41:20 JaMa: I think I might have a line on it, can you test the following, change libtool-native to have this for it's value: CACHED_CONFIGUREVARS += "CONFIG_SHELL=${SHELL} ac_cv_path_SED=/bin/sed" Sep 12 21:44:58 trying now Sep 12 21:47:35 is that for the missing sed bug? meaning the silly one i wrote... Sep 12 21:49:00 nm... Sep 12 21:50:34 any reason why LICENSE_${PN}-whatever = "something" wouldn't work to give a sub-package a different LICENSE? Sep 12 21:51:07 should work fine Sep 12 21:51:17 I suppose that might defeat some of the license manifest etc. infrastructure? or no? Sep 12 21:51:27 nope, it can handle that fine Sep 12 21:51:36 it has code to handle that specifically Sep 12 21:51:52 excellent. thanks. Sep 12 21:54:43 Hmm, I need to find the time to finish the automatic python deps stuff i was working on.. fighting too many fires Sep 12 22:10:51 anyone else having insane lag on Freenod today? Sep 12 22:25:05 Anyone doing meta-ivi builds? I'm getting common-api-c++-dbus failures Sep 12 22:30:45 sgw_: is seems to store SHELL in libtool script now, but is SHELL variable replaced when reusing archive from sstate? Sep 12 22:30:49 sgw_: if I set SHELL to /my/private/foo/bash, create sstate archive for SSTATE_MIRROR, will it work on other hosts? Sep 12 22:32:09 all the text files / scripts get the paths sed'd in and out of sstate, so as long as the path is in the sysroots, should be fine, afaik Sep 12 22:42:08 kergoth: it's hosts path (e.g. /usr/local/bin/bash) not sysroot specific Sep 12 22:43:09 ah, sstate would leave that as is, afaik **** ENDING LOGGING AT Fri Sep 13 02:59:58 2013