**** BEGIN LOGGING AT Mon Nov 03 03:00:00 2014 Nov 03 06:49:47 Gm:) Nov 03 07:27:18 good morning everybody Nov 03 07:28:08 I feel dizzy Nov 03 07:29:24 My code doesn't compile yet with dizzy. Somehow build intermediates are in a work/.../build folder now, so are my autogenerated header files. But that location is not in the include paths... Nov 03 07:57:39 good morning Nov 03 09:47:08 morning all **** BEGIN LOGGING AT Mon Nov 03 10:08:03 2014 Nov 03 12:08:44 hi, how can I check if Yocto is trying to pass the correct ld library path to my build system? Nov 03 12:08:47 bitbake -e foo Nov 03 12:08:57 | grpe ^LD_LIBRARY_PATH does not bring up anything. Nov 03 12:09:17 but my tool run during the buildsystem steps cannot find the libncurses library even though it ought to be available. Nov 03 12:17:57 lpapp_: my guess is that the built target compiler uses its own sysroot by default Nov 03 12:18:08 into which libraries are installed Nov 03 12:18:54 e.g. build/tmp/sysroots/qemux86-64/usr/lib Nov 03 13:04:03 hundeboll: hmm? Nov 03 13:34:44 hi. i am wondering how to extract a basic toolchain from a yocto sdk, so i can use it with buildroot? Nov 03 13:35:24 ericbutters: lol Nov 03 13:36:56 :) Nov 03 13:37:28 i only got the sdk, so i need to build some packages.. but not with yocto in that case Nov 03 13:37:47 i did not built the sdk by myself Nov 03 13:39:23 lpapp_: any idea? Nov 03 13:40:06 ericbutters: cannot you tell buildroot to use the path from the yocto sdk with regards to the toolchain? Nov 03 13:40:11 ericbutters: the SDK basically is just the toolchain, so I don't think there's much to extract... Nov 03 13:42:45 bluelightning: yes that is right, and i thought it should be clear to use it. but i got erros at first buildsteps og BR and i read "We do not support toolchains or SDK generated by OpenEmbedded or Yocto, because these toolchains are not pure toolchains" Nov 03 13:43:14 ericbutters: you'd have to talk to the buildroot folks about that I guess Nov 03 13:43:35 yes Nov 03 13:43:50 I'm no expert for sure, but I'm not sure what qualifies as a "pure toolchain" Nov 03 13:45:33 vanilla? Nov 03 14:00:44 hey, lets say i have only got the yocto sdk.. is it possible to use yocto with that sdk to build a package? Nov 03 14:02:06 yocto does not need the yocto sdk Nov 03 14:02:30 to be clear: i only want to build a package, not an sdk Nov 03 14:02:46 still, you do not need the yocto sdk generated for that. Nov 03 14:04:08 but yocto first must generate a toolchain, so you mean first is to say 'bitbake meta-toolchain' and then 'bitbake package' ? but as i got already a yocto toolchain from my supplier i want to use that one Nov 03 14:04:47 i want to tell yocto to use that provided toolchain to build a package Nov 03 14:04:50 I think it is better to generate it once and use sstate cache, eventually. Nov 03 14:05:10 rather than messing with untested external toolchain setup like that. Nov 03 14:05:27 to generate it i need the setup from the supplier which i do not have Nov 03 14:06:03 sorry, do not know what you mean. Nov 03 14:06:09 np Nov 03 14:09:18 I mean the same setup you need to build any package, more or less. Nov 03 14:09:31 whether it is toolchain or/and some other thing, that is nearly identical. Nov 03 14:14:04 ericbutters: our build system is not designed to take its own SDK as an external toolchain Nov 03 14:14:52 you may need to contact your supplier and ask them for a layer which supports the target hardware Nov 03 14:16:49 bluelightning: i see, thanks for information Nov 03 14:20:24 hundeboll: I am a bit surprised how ncurses works just fine for gdb-cross Nov 03 14:21:03 wait, I actually have not tried to run gdb-cross from a buildsystem, just separately. Nov 03 14:21:38 I guess that is a totally different issue because when you run it, it will likely know where to look for the libraries based on the path, I would assume so. Nov 03 14:21:51 but during buildtime, I am not sure... Nov 03 14:22:27 as a workaround, I would happily hand-craft some LD_LIBRARY_PATH in the make fucntion of the Yocto recipe, but I do not even know which path to hard code there... Nov 03 14:23:24 I guess I will use the one from build/tmp/sysroot or something. Nov 03 14:28:20 lpapp_: I think you have ${sysroot} available in the receipes Nov 03 14:31:17 hundeboll: returning the target sysroot or the generic? Nov 03 14:31:28 I should probably print it out to see, I guess. Nov 03 14:31:32 no idea :) Nov 03 14:41:16 hundeboll: echo $sysroot -> empty output :( Nov 03 14:42:53 dylan here. Nov 03 14:46:18 what is "meta-ide-support" ? Nov 03 14:47:31 check the layer description, if it confirms the guidelines, it should explain it. Nov 03 14:48:27 it isn't in the layer index Nov 03 14:48:47 lpapp_: please provide a link to detail Nov 03 14:48:59 ericbutters: to what detail? Nov 03 14:49:35 ah, it is in oe-core Nov 03 14:49:40 lpapp_: cman :) detail to meta-ide-support Nov 03 14:49:53 DESCRIPTION = "Meta package for ensuring the build directory contains all appropriate toolchain packages for using an IDE" Nov 03 14:50:01 ericbutters: https://github.com/openembedded/oe-core/blob/master/meta/recipes-core/meta/meta-ide-support.bb Nov 03 14:50:35 lpapp_: thanks Nov 03 14:52:09 does this what i need? a simple toolchain extraction? why there is not such functionality in yocto? Nov 03 14:52:35 heh, you are still stuck with that :D Nov 03 14:53:01 why don't you just ask your supplier if you need support from them? Nov 03 14:53:15 it is possible that even if you set it up, you will need to know platform specific details, etc. Nov 03 14:53:34 lpapp_ because i can not ask them each time i need to build 3rd party sw Nov 03 14:54:54 yocto sdk from a customer pov help with build their own sw, but as soon as they need 3rd party they are stuck with yocto Nov 03 14:54:57 sdk Nov 03 14:55:47 you always need to know how to cross compile.. instead of using buildroot or yocto for that Nov 03 14:56:49 and i really can not believe that yocto as no option to generate a "pure" toolchain Nov 03 14:57:17 it seems to me that you have insufficient communication with your partner. Nov 03 14:57:54 I still have no idea what pure toolchain means. Nov 03 14:58:23 just assuming it means vanilla, but I do not see Yocto heavily patching the toolchain. Nov 03 15:10:15 what would be great: let users install any yocto sdk and then use bitbake and meta layers to build packages with that :) Nov 03 15:12:04 I think that makes not much sense, really. Nov 03 15:12:16 Yocto is meant for doing that, but then you want to avoid Yocto... what is the point? Nov 03 15:12:31 not to improve the communication with your co-workers? Nov 03 15:13:26 lpapp_: that makes perfect sense to me.. why not making life easy? why making it hard? Nov 03 15:13:32 if one has to generate recipes, that person needs to work with the rest of yocto developers. Nov 03 15:13:45 exactly my point, imho you are making it hard Nov 03 15:13:54 you both need to work with _yocto_, yet you do not communicate Nov 03 15:13:54 i want to use receipes not making one Nov 03 15:14:21 you do not share the work, etc. Based on my experience, it happens to people when they do not communicate properly. Nov 03 15:17:10 lpapp_: you do not get my point.. i do not contribute to yocto in that case.. i want to use yocto without building a sdk.. just to build a package to use with a target based on my suppliers sdk.. so in the world today with yocto i have to ask my supplier to build that for me and that costs money.. or i cross compile by myself and that takes time and money. so why not using yocto then? that would be easy, take the sdk from supplier and use yocto. Nov 03 15:17:52 ericbutters: lpapp_ isn't necessarily speaking for all of us.. FWIW whilst we might not be able to do exactly what you are asking (for a number of reasons) we do intend to provide an easier means of building additional pieces of software for the target Nov 03 15:17:57 i heared that suppliers can do meta-layers for that purpose Nov 03 15:18:18 ericbutters: I would fix your business model. Nov 03 15:18:32 if your established deal is so inflexible to work together, it is screwed imho. Nov 03 15:18:42 lapp_: i think you did not work much with suppliers :) Nov 03 15:18:45 I mean it is quite common in every project that someone contributes back. Nov 03 15:18:54 ericbutters: never, I am begging on the street :p Nov 03 15:19:11 joke aside, I am actually currently heavily working with a supplier. Nov 03 15:19:24 ericbutters: however if your current work is to build an image that goes onto the target device, then you should really have a proper BSP layer to support that Nov 03 15:19:47 bluelightning: he clearly indicated he does not want to build an image, just a package Nov 03 15:19:57 so that he can, I guess, install that by the package manager. Nov 03 15:20:14 I was missing that feature a while ago and complained about it, but then I was told it is corner case, so I accepted that. Nov 03 15:20:19 lpapp_: right now, yes... but is that the end goal? Nov 03 15:20:24 and eventually moved on. Nov 03 15:21:08 bluelightning: this is my understanding: his supplier provides the image, and he would like to package his software onto the target using the Yocto sdk. If it is deb or rpm, I do not understand why recipes need to be used though. Nov 03 15:21:38 (even if it is ipkg, it could be done separately, so I am not sure what is the matter with recipes) Nov 03 15:22:02 perhaps it would be easier, that is why, and more portable. Nov 03 15:22:18 bluelightning: i got the image (kernel and rfs) as well as the sdk from the supplier. and everything building my own software is fine.. but sometimes i need some tools which i always need to cross compile myself, and i was wondering why there is no option to use yocto Nov 03 15:23:07 lpapp_: i would love it to be able to use a package manager for that. but that is not an option Nov 03 15:23:31 please read this: http://www.yoctoproject.org/docs/1.6.1/adt-manual/adt-manual.html Nov 03 15:24:39 ericbutters: part of the goal of our system is to avoid the situation where you are cobbling together images out of binary pieces outside of the build system, leaving you with something that in the long term is difficult to maintain Nov 03 15:25:11 ericbutters: maybe you aren't doing that, but FWIW enabling that particular use case isn't really what our project is for Nov 03 15:26:34 ericbutters: if you cannot use a package manager, but you want to package, just confuses me even more. Nov 03 15:26:56 I guess you would need to explain what packaging means in your definition. Nov 03 15:27:13 bluelightning: that makes sense to me.. and i see what you mean further. so with yocto you are stick to your sdk provider. or you are doing it on your own. so do not get me wrong, i like what yocto does. but as i said, from my POI, it would be nice to be able to use yocto without building an image/sdk Nov 03 15:27:52 I do that every day, cannot see the problem Nov 03 15:28:02 you definitely do not need to build an sdk for using Yocto Nov 03 15:28:27 i also do not want to build a toolchain, just using it Nov 03 15:28:31 but again, your definition of SDK may vary... that is why it is confusing to discuss it. It would be nice to know all the details including the definitions. Nov 03 15:28:52 you have to build it once. Nov 03 15:28:59 what is the matter? Nov 03 15:30:14 I mean, sure, 1 > 0, but if you have got zero from your supplier, what is the problem? Nov 03 15:30:20 what target is it, etc? You did not share much details. Nov 03 15:32:57 does it require difficult BSP? Nov 03 15:43:05 lpapp_: no it is simple as i explained. and it is no matter iof what is the target or the BSP. all i say is that let yocto reuse a given yocto sdk. thats it. Nov 03 15:51:39 ericbutters: OK, I disagree. IMHO, there is no use case for that :) Nov 03 15:52:08 (or if there is any, that means either corner case or an issue elsewhere) Nov 03 15:52:35 the thing is, you already made up your mind. Nov 03 15:54:11 lpapp_: if you are going to talk to people in here can I ask that you do so politely... right now you aren't helping Nov 03 15:54:39 bluelightning: I am sorry to disagree. Nov 03 15:55:14 and I do intend to help. It is not my problem that someone has made up his mind, and will not change it no matter what help he gets. I did ask for clarification, but could not get any response out of it. Nov 03 15:55:23 so probably he does not actually need help to solve the issue for today. Nov 03 15:55:53 otherwise, I assume he would have provided answers so that I can give advices. Nov 03 15:57:06 and complaining here about it will not help anyway; if you want a corner case to be considered, go to the bugtracker. Nov 03 15:57:19 (although that is usually closed, too, in such cases in my experience) Nov 03 15:59:02 ericbutters: please do not complain here about as it will not get implemented here; you do not want to pay to your suppliers, fair, the Yocto people may be cheaper. Go to the bugtracker and report it: https://bugzilla.yoctoproject.org/ Nov 03 15:59:20 but do not be surprised if it is closed as won't fix. Nov 03 16:00:05 if you want workarounds for today, you have to share more details, otherwise you will remain without proceeding, really. Nov 03 16:04:32 lpapp_: please do not discourage people from discussing things here Nov 03 16:05:53 lpapp_: i kindly wanted to ask for thinking about such a feature in future. but as bluelighning explained, that is not what yocto is meant for. Nov 03 16:06:40 ericbutters: I do not understand bluelightning, imho he is saying conflicting things Nov 03 16:06:51 initially he wrote that yocto would support such things and then not. Nov 03 16:07:14 I am lost at that conflict, but if you think it is such a cool feature, I would surely report it, no matter what one person thinks here. Nov 03 16:07:25 I did that many times myselef. Nov 03 16:07:26 I give up Nov 03 16:07:27 myself* Nov 03 16:07:55 15:16 < bluelightning> ericbutters: lpapp_ isn't necessarily speaking for all of us.. FWIW whilst we might not be able to do exactly what you are asking (for a number of reasons) we do intend to provide an easier means of building additional pieces of software for the target Nov 03 16:08:03 and Nov 03 16:08:04 15:23 < bluelightning> ericbutters: part of the goal of our system is to avoid the situation where you are cobbling together images out of binary pieces outside of the build system, leaving you with something that in the long term is difficult to maintain Nov 03 16:08:09 15:23 < bluelightning> ericbutters: maybe you aren't doing that, but FWIW enabling that particular use case isn't really what our project is for Nov 03 16:08:23 to me, those two points are conflicting, so I cannot make sense out of them together currently. Nov 03 16:09:14 that is with due respect before people start becoming emotional and losing the track of being objective. Nov 03 16:11:46 ericbutters: and fwiw, he is not the main yocto maintainer, so if I was feeling cool about a feature regardless one person thinks - except if it is the main maintainer -, I would say, I would just report it, or even then if everyone disagrees for public recording when the blame game starts later. Nov 03 16:12:31 lpapp_: i am going to report it as a feature request Nov 03 16:12:36 ok Nov 03 16:12:39 good luck :> Nov 03 16:12:40 I don't see is as conflict, my understanding is that 1st part is about not making 3rdparty binary components un-necessary difficult, 2nd part is recommendation to try to prevent it and build everything from source in one OE build Nov 03 16:13:35 and I agree with both parts, we have a lot of binary components built outside OE and it's a lot of pain Nov 03 16:14:17 not inflicted by OE as build system Nov 03 16:14:18 JaMa: building outside OE means you did not use bitbake and yocto meta layers? Nov 03 16:14:28 yes Nov 03 16:14:50 but that is not what ericbutters wants based on his description. Nov 03 16:14:58 (in my understand of course) Nov 03 16:15:00 yes, that is what i say, it it lot of pain then.. it would be nice to be able to re-use yocto then Nov 03 16:15:02 understanding* Nov 03 16:15:25 sorry I haven't read whole backlog, I was responding mostly to parts you copy-pasted from bluelightning Nov 03 16:15:41 well, it needs to be put in context ^_^ Nov 03 16:18:20 lpapp_: that is what i said.. you got a yocto image on and a yocto sdk delivered, and then you want to build a tool like a browser, ie firfox for this.. so you got two options: 1. ask the supplier to build it -- or 2. build it on your own. but the later is not that easy.. and therefore there is yocto or buildroot Nov 03 16:20:04 lpapp_: but maybe that is a corner case, okay.. but i am stuck here right now. and i thought why not re-using the sdk i got.. Nov 03 16:20:30 but that is not working, not with yocto and not with buildroot Nov 03 16:20:35 ericbutters: is there 3rd option? because these 2 are relatively well covered by OE Nov 03 16:20:49 ericbutters: I still do not get why 2) is difficult Nov 03 16:20:59 ericbutters: in my experience, you source the environment script Nov 03 16:21:10 and then you build your software the regular way unless its buildsystem is silly. Nov 03 16:21:12 JaMa: no not as i know :) Nov 03 16:21:28 ericbutters: the 1st one is pain, because you need to send your SDK to browser supplier Nov 03 16:21:31 and that is the whole point, you know? Nov 03 16:21:34 lpapp_: for building my software it is okay Nov 03 16:21:41 I keep telling you that you do not need a recipe Nov 03 16:21:43 but for 3rd party sw... Nov 03 16:21:51 you do not need Yocto for that. Nov 03 16:22:01 ericbutters: and in some cases you're maintaining multiple versions at the same time, but your browser supplier needs to build the same code multiple times for each SDK you delivered to him Nov 03 16:22:03 ericbutters: why? Nov 03 16:22:06 lpapp_: okay explain how to do it Nov 03 16:22:09 please Nov 03 16:22:25 "in my experience, you source the environment script and then you build your software the regular way unless its buildsystem is silly." Nov 03 16:22:48 you said you did not need packages, so that oughta suffice, I presume? Nov 03 16:23:02 lpapp_: right, that is how i do with my own source Nov 03 16:23:34 but how to configure correct for cross build? that all is done proved and correct by yocto receipes Nov 03 16:23:49 and i need to do by my own.. that is my problem Nov 03 16:24:14 lpapp_: i said i *need* packages.. Nov 03 16:24:45 you have to read carefully Nov 03 16:24:47 I will quote yourself, sec. Nov 03 16:25:06 that is all about here.. all the discussion. Nov 03 16:25:10 15:21 < ericbutters> lpapp_: i would love it to be able to use a package manager for that. but that is not an option Nov 03 16:25:33 so how can you use packages if package manager is not an option, please? Nov 03 16:25:39 "but that is not an option" -- what does this mean? i can not use an package manager Nov 03 16:25:59 if you cannot use a package manager, how can you use packages? Nov 03 16:26:18 eyyy.. i want to build a package and then use it Nov 03 16:26:35 how if you cannot use a package manager to use the package? Nov 03 16:27:38 okay.. package=some program/source that is build with bitbake.. so sorry for that.. Nov 03 16:28:03 by package you mean an executable? Nov 03 16:28:09 yes Nov 03 16:28:19 see, this is why your definitions make it confusing to discuss Nov 03 16:28:25 that is not what usually people think about packages. Nov 03 16:28:39 and that is why I keep telling you to share your definitions to be on the same page. Nov 03 16:28:49 okay you are right.. that was very confusing Nov 03 16:28:52 right, so what is wrong about regular cmake/qmake/make/autotools/ninja/scons/whatnot? Nov 03 16:28:58 they will generate executables for you, too. Nov 03 16:29:46 but why to use different things and not using all in one called yocto.. that does this for me with one command? Nov 03 16:30:29 and what is the matter re-using an yocto sdk with yocto? Nov 03 16:31:02 or why there is no option to extract a simple toolchain out of the sdk? Nov 03 16:31:10 too unusual; Intel and LF did not need it. Nov 03 16:31:44 my opinion is that the business usually does not demand such an unreasonable scenario where you cannot collaborate for good. Nov 03 16:32:00 since if you do the layer Y on top of layer X yourself, that layer Y will not be usable for others. Nov 03 16:32:11 if it is integrated back to your supplier, they can give it to others off-hand. Nov 03 16:33:12 or at least you should get the BSP Yocto sources, etc. Nov 03 16:33:20 lpapp_: i do not touch any layer or create one.. i simple want to use yocto to build an executable for my target platform.. simple.. Nov 03 16:33:28 but then again, I asked many times what your BSP is Nov 03 16:33:37 it is possible it just works, and you do not need any customization Nov 03 16:33:41 but you did not want to share that bit... Nov 03 16:34:09 how will you build your software without an own layer? Nov 03 16:34:17 freescales imx6 bsp.. but the supplier made his own things, so the toolchain has special tune parameters etc. Nov 03 16:35:26 my supplier is not freescale, and i really do not know what all is done by him to the freescale meta layers.. but all that is not what i want to know.. Nov 03 16:36:43 lpapp_: i see, there is no way today for my needs here.. Nov 03 16:36:58 there sure is :) Nov 03 16:37:12 JaMa: how did you build 3rd party software outside yocto? Nov 03 16:37:37 lpapp_: then please tell me. Nov 03 16:39:18 lpapp_: i got: yocto sdk for my target platform -- i need: let yocto build firefox with that sdk Nov 03 16:40:08 ericbutters: try to hard code the toolchain for your "image". Nov 03 16:40:16 in some common config. Nov 03 16:40:31 ericbutters: unpack SDK, source the script, run whatever build system your component is using to generate the binaries Nov 03 16:41:53 JaMa: okay.. i see. i do not have a build system for that.. that is the issue. yocto is a build system Nov 03 16:42:25 by build system I meant cmake,qmake,automake,... Nov 03 16:42:36 lpapp_: that is the feature i am asking for.. why do i need to hack this? but anyway that is a solution.. so please advise more Nov 03 16:42:56 advise more? :O Nov 03 16:43:11 JaMa: okay, but there you got the configuration already setup Nov 03 16:43:58 ericbutters: I would consider your use case valid, if the situation is really that broken, but it is luckily not the usual case in my experience. Nov 03 16:43:59 the configuration (of the tools) is part of SDK script, the rest is configured by cmake/qmake/autotools Nov 03 16:44:26 lpapp_: that is no magic that you do.. that there is a way by hacking is clear to me.. magic is to tell where and how to hack.. better provide some gist/patch :D Nov 03 16:44:53 JaMa: the only problem I see with that if you need to build multiple software pieces with dependencies, etc. Nov 03 16:45:04 but I still think that is a very rare case based on my industrial observation. Nov 03 16:46:17 lpapp_: yes that's the pain I was mentioning before, we have multiple SDKs (with different versions of dependencies) and we need to get the 3rdparty binaries rebuilt multiple times even when it's from the same source Nov 03 16:47:19 and then we include SDK indentifier in the filenames of binary packages we're receiving back Nov 03 16:47:20 ericbutters: read about the config files. You could do it in your distro, image, local, site, etc. Nov 03 16:48:16 ericbutters: but if some buildsystems override that insanely, you are outta luck. Nov 03 16:48:25 lpapp_: i would really appreciate if you can help here Nov 03 16:48:39 last time we were even running ABI checker to see what differences in SDK versions are important and we're rebuilding only components which are linking against some dependency with incompatible ABI (compared to previous SDK version) Nov 03 16:49:28 ericbutters: well, that is all that my resources allowed me today... Nov 03 16:49:59 we save some work to 3rdparty builders, but make it a bit more complicated to get consistent set of binary packages all with compatible ABIs Nov 03 16:50:31 ericbutters: I suggest you to listen to JaMa. Nov 03 16:54:34 JaMa: do you know by any chance how I could access to the ncurses library in my buildsystem? Nov 03 16:54:55 since the tool that I run during the make run does not find it which depends on it, I thought I would work it around with modifying the LD_LIBRARY_PATH Nov 03 16:55:06 but I cannot find a variable to the library path. Nov 03 16:55:37 so the use case is that I build for arm, and try to run an intel tool during the buildsystem run, but it cannot find the libncurses "so" file. Nov 03 16:57:30 lpapp_: ncurses's pkg-config file doesn't provide the path? Nov 03 17:04:34 JaMa: hmm, that is a good hint, thanks, I will look at it. Perhaps I can use a variable in Makefile that way. Nov 03 17:19:09 jama: it seems it cannot be found because my yocto environment is in x86_64 Nov 03 17:19:17 and that particular tool is 32 bit Nov 03 17:19:32 how can I enforce the ncurses-native to be available in 32 bit (too?) Nov 03 17:20:39 dunno, I would probably use 32bit SDK if you need to call 32bit tools from it Nov 03 17:21:17 yeah, that would make sense for a bit more complex clash, but it is just one package and I have the setup already for everything Nov 03 17:21:24 so the porting would take quite a bit of effort. Nov 03 17:21:37 is it not possible with yocto to say DEPENDS = ncurses-native:32 or something? Nov 03 17:22:08 also, we need 64 bit tools as well at other places... a bit of mess, it is ... Nov 03 17:23:00 my only idea is to copy the recipe and enforce 32 bit in our layer Nov 03 17:23:28 (if the buildsystem of theirs supports that at all) Nov 03 17:23:58 so what I need is not only the dependency name, but dependency arch and platform. Nov 03 17:31:46 JaMa: as I need to leave soon, I asked this on the mailing list. Nov 03 17:34:07 lpapp_: sorry I'm on conf call Nov 03 17:35:06 np Nov 03 18:56:05 ericbutters: sorry if I had sounded impolite before. ;-) Nov 03 20:52:24 Evening. I've got a custom type of file that I use to produce fully self contained loads that I want to produce via an image recipe. They combines kernel, filesystem and a few other bits and bobs. I can easily run a script to generate it from a recipe but is there a more elegant way to do things? I've noticed "DEPLOYABLE_IMAGE_TYPES" when looking around, would that be a sensible mechanism to use and has anyone produced any examples of extending? **** ENDING LOGGING AT Tue Nov 04 03:00:00 2014