**** BEGIN LOGGING AT Tue Apr 28 02:59:59 2015 Apr 28 06:01:12 how can I make the systemd startup log colorized? Apr 28 07:01:13 Hi All Apr 28 07:03:19 is there a difference in behaviour if i put this line DISTRO_FEATURES_remove = "x11 directfb" in local.conf versus if i put the line in an core-image-XXX.bb file ? Apr 28 07:03:47 darkspike: there is: it will work in the .conf file, it won't work in the .bb file :) Apr 28 07:04:34 darkspike: reason: variables that are set in a .bb file are only visible during build steps related tho that particular recipe. which is certainly not what you want for DISTRO_FEATURES Apr 28 07:05:54 LetoThe2nd: ahaaa... ok, thanks ! :) Apr 28 07:06:57 darkspike: for things like that, better derive your own distro.conf. poky-bleeding is a good example, and then use that for your builds. Apr 28 07:07:18 local.conf is not really what you want for being able to reproduce stuff reliably. Apr 28 07:13:07 good morning Apr 28 08:13:15 morning all Apr 28 08:13:18 hi.. doing a "if [ -a ..] inside do_unpack rises error: [: -a: unexpected operator Apr 28 08:16:13 ericbutters: do_unpack is a python function Apr 28 08:16:40 oh, thanks! Apr 28 08:19:24 bluelightning: how can i call a function (bash or phyton) from the do_unpack? Apr 28 08:24:44 ericbutters: bb.build.exec_func() Apr 28 08:24:52 ericbutters: git grep for examples Apr 28 08:25:32 ok Apr 28 08:45:30 Hi All !... i have IMAGE_INSTALL_append = "pack1" in the .bb file and IMAGE_INSTALL_remove = "pack1" in the .bbappend file. This does not seem to remove pack1.. What am i doing wrong ? Apr 28 08:47:11 darkspike: is there a leading space in the _appended value? Apr 28 08:47:22 bluelightning: could you pls see here: http://paste.ubuntu.com/ Apr 28 08:47:42 ericbutters: I'll need the correct URL... Apr 28 08:47:51 sry Apr 28 08:48:03 http://paste.ubuntu.com/10922832/ Apr 28 08:48:07 bluelightning: yes there is :( Apr 28 08:48:46 darkspike: with bitbake -e $YOURIMAGERECIPE you should get a list of all operations on IMAGE_INSTALL (grep for it) Apr 28 08:48:57 darkspike: maybe you can see where it goes astray there. Apr 28 08:49:13 darkspike: and, _remove is only there since dora (10.0) BTW Apr 28 08:49:19 ericbutters: erm... hmm... maybe that earlier error wasn't assuming it's a python function Apr 28 08:51:56 ericbutters: right... your problem originally was -a is not a unary operator and you were attempting to use it as one - maybe you didn't mean -a ? Apr 28 08:51:56 LetoThe2nd: i am trying to correct an error with the _remove, so bitbake -e is not working for me at this point Apr 28 08:52:21 LetoThe2nd: can debug the assignments of the IMAGE_INSTALL some other way ? Apr 28 08:52:27 darkspike: well of course, if the recipes don't even parse... hm Apr 28 08:52:39 darkspike: what about IMAGE_INSTALL += "my_funny_package" Apr 28 08:52:57 darkspike: what error are you attempting to correct exactly? Apr 28 08:53:50 bluelightning: ERROR: Nothing RPROVIDES 'xserver-xorg-module-libwfb' Apr 28 08:54:35 darkspike: and that's definitely being added directly to IMAGE_INSTALL, and not coming in as a dependency of something else? Apr 28 08:54:53 if i remove xserver-xorg-module-libwfb line from the .bb file it works, but i don't want to remove the line because the layer is not mine... Apr 28 08:55:34 it is not a dependency of something else 'cause if i remove it from the .bb file it is not complaining any more about it Apr 28 08:55:42 my suggestion here would be to simply create your own image recipe Apr 28 08:56:11 logically the _remove should work but there are probably operation order issues getting in the way Apr 28 08:57:11 yes... can i somehow see the operation order somehow ?... Apr 28 08:57:20 not in this situation, no Apr 28 08:57:41 there's a bug open for bitbake -e being blocked in this situation, FWIW Apr 28 08:57:44 image recipes are usually so trivial that there's not much gain in trying to build on an existing recipe Apr 28 08:57:48 ok, thanks !.. i'll dig on :) Apr 28 09:15:14 Hi. I have a little problem. I am trying to build fsl-image-multimedia-full without X11 support, but with gst plugins, but in fido it fails because gstreamer1.0-plugins-good-cairo requires some X packages like libxdmcp6. How can I fix it? (in dizzy all was good( Apr 28 09:21:16 bluelightning: using "-e" works Apr 28 09:28:05 bluelightning: how to checkout a single file from svn using SRC_URI? lets say i got svn setup like http://paste.ubuntu.com/10923152/ and i want to checkout targetfs-ericbutters.tgz ?? Apr 28 09:29:59 ncgs: the recipe looks like it has the correct dependencies set, so I can only assume an erroneous dependency exists within the cairo plugin Apr 28 09:30:23 ncgs: if you don't need the cairo plugin you could disable that by setting PACKAGECONFIG for the recipe such that it does not contain "cairo" Apr 28 09:30:30 Hi guys. I'm having a problem with building ruby-native 2.2.1 on Ubuntu 12.04 x86_64 using release 'fido'. Problem log is here: http://pastebin.com/wwrEia7w Apr 28 09:30:45 ericbutters: I really don't know, does subversion even support that itself? Apr 28 09:31:34 Can anybody with the same or similar setup give a "bitbake ruby-native" to test if it's only me, or it's a common problem? Apr 28 09:31:36 bluelightning: good point Apr 28 09:32:48 ericbutters: ultimately we just call subversion, so if not, we can't support it either Apr 28 09:35:08 robertz: not positive but it kind of looks like dtrace is being half-enabled - do you perhaps have some part of dtrace installed on your host system? Apr 28 09:39:43 bluelightning: no 'dtrace' command installed. Should I check something else? Apr 28 09:41:11 (haven't tried to install dtrace explicitly either) Apr 28 09:42:01 I'm not sure, you'd have to look at how ruby checks to see if it should enable this functionality Apr 28 09:42:19 my knowledge of ruby and its build system is practically nonexistent Apr 28 09:43:25 but it would presumably be something it would be checking within do_configure Apr 28 09:44:37 bluelightning: yeah, looking right now. It looks something about dtrace is there. Thanks for the precious hint, will let you know Apr 28 10:03:03 robertz: wohooo. Adding "--disable-dtrace" in the recipe fixed it for me. I'll report it to Armin Kuster to fix it. Thank you bluelightning, you're again the Yocto hero! Apr 28 10:03:49 robertz: glad to be able to help :) Apr 28 10:05:52 Is it possible to customize the generated hddimg without manually re-generating it using wic? Apr 28 10:07:14 CromFr: what kind of customisation were you thinking of Apr 28 10:07:16 ? Apr 28 10:07:16 (by customizing I mean partition type, size, etc... Apr 28 10:07:36 I'm afraid not... that's really what wic is designed to do Apr 28 10:07:56 is there a way to automate it? Apr 28 10:08:16 not at the moment, but there has been some discussion about it Apr 28 10:08:40 ok thx Apr 28 10:09:42 bluelightning: can we backport this fix to the daisy branch? http://ftp.arm.linux.org.uk/cgit/linux-arm.git/commit/?h=for-next&id=7fc150543c73de71859631c8a6b17e3067fe7617 Apr 28 10:10:24 which means updating the compiler ^_^ Apr 28 10:10:36 lpapp: er, that's not a fix, that's immediate build breakage ;) Apr 28 10:10:37 the kernel daisy is using is buggy Apr 28 10:10:47 the daisy branch* Apr 28 10:10:57 eh, gcc, I mean. Apr 28 10:11:00 well, we'd need the compiler fixed, that would be the correct way to address this Apr 28 10:11:09 looks like a really bad choice to have been taken for me. Apr 28 10:12:29 having said that I can only assume that people have been successful in building kernels using the version of gcc in daisy; so how does your situation differ? Apr 28 10:13:00 arm kernel? Apr 28 10:13:04 are you sure? Apr 28 10:13:15 it is a subtle bug. Apr 28 10:13:25 I do not yet know whether it fixes my issue Apr 28 10:13:27 but it is nasty anyway Apr 28 10:13:43 I could not test it yet since I really do not know the gcc fix for this ... Apr 28 10:13:52 and I really cannot find binaries from Linaro for 4.8.X Apr 28 10:13:56 only for 4.9.X, et al. Apr 28 10:14:09 and I really did not want to go that far from 4.7 which is what dylan used to have. Apr 28 10:15:26 bluelightning: https://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_8-branch/gcc/config/arm/arm.c?r1=204665&r2=204664&pathrev=204665 Apr 28 10:15:36 it would be nice to backport that ASAP Apr 28 10:15:55 it is a very important fix, I would deem. Apr 28 10:16:04 it would be really strange to leave it out ... Apr 28 10:18:27 I get an error if I click on that link Apr 28 10:19:13 hmm, it seems that it is already integrated Apr 28 10:19:32 ../meta/recipes-devtools/gcc/gcc-4.8/0048-PR58854_fix_arm_apcs_epilogue.patch Apr 28 10:25:22 bluelightning: I am tempted to give a go to dizzy... Apr 28 10:25:25 that has 4.9, right? Apr 28 10:25:49 and skip daisy... we really wanted something more stable than daisy, but all the pain that went to it is getting outweighted by just using dizzy. Apr 28 10:25:59 at least, it would be quick enough to try. Apr 28 10:26:09 (hopefully, still need to read the migration from daisy to dizzy) Apr 28 10:32:56 lpapp: dizzy has both 4.8 and 4.9 Apr 28 10:33:46 much as I applaud your upgrading, if the problem is not in gcc you may still suffer the same problem Apr 28 10:34:59 yes, I checked the source that it had recipes for both Apr 28 10:35:11 what is the proper way to override another recipe? * base-files is creating a file that i want to override on a layer Apr 28 10:35:12 but when I issue bitbake myimage, which one will it use by default? Apr 28 10:35:22 I do not know which is the preferred, I should grep, I think ... Apr 28 10:35:44 miandonmenmian: .bbappend Apr 28 10:35:50 i was thinking to tell my recipe to delete the file on do_install then put the other file. but not sure.. Apr 28 10:35:50 or if it is too complex, ship your own Apr 28 10:36:03 as far as base-files goes, we ship our own as a complete replacement Apr 28 10:36:03 oh, interesting, thanks lpapp Apr 28 10:36:05 but it is not ideal Apr 28 10:36:05 will try Apr 28 10:36:25 not ideal to ship your own ? Apr 28 10:36:34 bluelightning: yes, I agree, but "What could go wrong?" hah. Apr 28 10:37:01 .bbappend needs the same name as previous package? Apr 28 10:37:01 joke aside, I would have no other tip than the compiler as the kernel is verbatim and we figured that bitbake has not changed the rules recipes are parsed, etc. Apr 28 10:37:07 miandonmenmian: yeah Apr 28 10:37:22 recipe, not package, but yeah. Apr 28 10:38:33 bluelightning: so do you know off-hand the default preferred version? Apr 28 10:38:45 what is /etc folder called on bitbake? or how can i find names for these directories on bitbake? Apr 28 10:38:55 check existing recipes, please. Apr 28 10:39:21 but it is ${sysconfdir} Apr 28 10:39:47 lpapp: 4.9 it would appear Apr 28 10:39:59 thanks lpapp Apr 28 10:49:55 bluelightning: thanks, I also concluded that Apr 28 10:50:09 bluelightning: good that the minimum git version for dizzy is satisfied by lenny. Apr 28 10:50:15 (debian lenny, thati s) Apr 28 10:50:17 that is* Apr 28 10:54:57 even if it were not, buildtools would provide it... Apr 28 10:56:20 yeah, but I like simplicity ^_^ Apr 28 11:41:17 bluelightning: hmm, I am facing the first daisy to dizzy update issues Apr 28 11:42:19 bluelightning: https://paste.kde.org/puiu1thbt Apr 28 11:42:53 again some scope changed similarly to "which" in daisy? Apr 28 11:59:29 Exception: AttributeError: 'module' object has no attribute 'contains' Apr 28 12:05:15 lpapp: sigh... nobody noted that oe.utils.contains() was replaced by bb.utils.contains() Apr 28 12:07:11 I am doing a clean build to see if I can reproduce it. Apr 28 12:07:17 perhaps I had some stray files around. Apr 28 12:08:42 unless one of those "stray" files was systemd_211.bb, that won't fix it Apr 28 12:14:42 is it normal that meta/recipes-core/initrdscripts/files/init-install-efi.sh does not contain any call to grub-install ? I don't understand grub/efi to answer that myself but it seems weird... Apr 28 12:15:01 and installing the live image on an EFI machine works... strangely for me Apr 28 12:36:20 hmm, so even if you set -r -b -k -n wic will still call bitbake internally? Apr 28 12:36:39 * JEEBsv is trying to add image creation into a bbclass Apr 28 12:43:34 JEEBsv: if you get it working, i'd be interested on how you did it... Apr 28 12:44:05 the only way I could find was to modify the install scripts of the live image, but that only works when installing from the live image (which is enough for my use-case) Apr 28 12:44:17 I was trying to do this in a recipe to package a udev rule and helper: Apr 28 12:44:19 UDEVDIR = "`pkg-config --variable=udevdir udev` Apr 28 12:44:21 EXTRA_OECONF = "--with-udev-dir=${UDEVDIR}" Apr 28 12:44:23 FILES_${PN} += "${UDEVDIR}/" Apr 28 12:44:55 but apparently the shell expansion won't work with FILES_${PN} ? Apr 28 12:45:41 boucman: well if your need is to just have a proper image created then you have boot-directdisk.bbclass Apr 28 12:46:00 which is IIRC currently hardcoded to ext2 I think? Apr 28 12:46:13 but in general possibly does what you want Apr 28 12:47:12 Hello. I'm getting a segmentation fault with wvdial. I have ran gdb on it and it seem that the crash is in libcrypto.so. Can anyone take a look at this please? http://pastebin.com/WfkMCZXf Apr 28 12:47:43 I'm running on master branch, arch arm, tune cortexa9. Apr 28 12:52:12 JEEBsv: my need was to change the default partitionning, have a separate data partition Apr 28 12:52:18 bluelightning: it seems that it built fine with a fresh rebuild. That is why I like fresh builds. Apr 28 12:52:23 changing the install script was the easiest way Apr 28 12:54:20 Sorry for the noise. I have captured the wrong thing. Apr 28 13:03:02 lpapp: unless your fresh build removed that bb file, your problem is still there somewhere Apr 28 13:03:47 bluelightning: I would not know! Apr 28 13:03:57 but it did, yes Apr 28 13:04:09 by fresh rebuild, I mean removing meta scripts bitbake and recopying them Apr 28 13:04:11 lpapp: you can easily find it by grepping ... Apr 28 13:04:16 previous I was overriding; that may have caused the issue. Apr 28 13:04:20 previously* Apr 28 13:04:26 since that does not remove old files. Apr 28 13:04:36 but this time I did make sure that old content is destroyed. Apr 28 13:04:45 in other words: pebkac. Apr 28 13:04:55 ok, well, that would explain the difference Apr 28 13:05:13 that's more than what a "fresh rebuild" would imply Apr 28 13:05:38 boucman: well you'd have to modify things for that in any case, just saying that there is some stuff that is already creating partitions that you could possibly base upon Apr 28 13:05:45 the only issue is if you want to use wic Apr 28 13:06:53 bluelightning: absolutely. Apr 28 13:11:09 JEEBsv: wic is a weird one... it is documented as the way to do what I wanted to do,but it's a separated tool from yocto i.e no recipe I could find use it. you need to use it "after the fact" on a pregenerated image Apr 28 13:11:33 not sure if that's how it's meant to be used or it's just that nobody has written/mainlined a recipe based on it... Apr 28 13:12:27 I think it was mentioned that there were some discussions regarding using wic in some bbclass/bb Apr 28 13:12:46 and that's what I was trying to do, finding out that wic depends on bitbake output Apr 28 13:13:31 bluelightning: unfortunately, it would not boot with 4.9 either. Apr 28 13:18:15 lpapp: I did warn you... Apr 28 13:18:37 bluelightning: well, it was worthwhile trying Apr 28 13:19:13 but this means I am pretty clueless as to why it does not work with two new gcc versions .... obviously, an unfixed bug would explain it, but I just cannot spot what exactly would fall apart ... Apr 28 13:27:29 lpapp: to me that suggests that the problem may be in the kernel rather than gcc Apr 28 13:29:56 bluelightning: that is also an option. Apr 28 13:32:53 bluelightning: I wonder whether it is worth trying with Linaro's binary toolchain Apr 28 13:33:00 downloadable from their site, without Yocto Apr 28 13:33:06 just to make sure this is not really a Yocto issue Apr 28 13:55:46 bluelightning: Hi! Apr 28 13:55:58 bluelightning: it's been a while, I hope you're doing well :) Apr 28 13:56:50 hi Marex Apr 28 13:57:00 indeed :) yes I'm doing well thanks, hope you can say the same? Apr 28 13:57:11 bluelightning: yep :) Apr 28 13:57:20 bluelightning: very fine, thanks :) Apr 28 13:58:00 bluelightning: I am struggling with the inheritance though Apr 28 13:58:45 bluelightning: is there some way I can check if Yocto bbclass exists at all ? If so, I'd like to return the name of the class, otherwise an empty string like you suggested Apr 28 13:59:08 Marex: not really no, but that wouldn't really be the right way to do this Apr 28 13:59:15 that'd solve my problem in an elegant way and finally let me get the fitImage upstream Apr 28 13:59:39 bluelightning: well, I don't quite want to steal your time on this, but a couple of hints would be really nice ;-) Apr 28 14:01:55 Marex: you want a function that returns the appropriate class name if KERNEL_IMAGETYPE contains the appropriate value, and "" if not Apr 28 14:02:15 bluelightning: the problem I'm look at is that if KERNEL_IMAGENAME is either fitImage or uImage, I want to inherit kernel-uimage or kernel-fitimage , otherwise I want to inherit nothing Apr 28 14:02:49 Marex: ok, then write a simple python function that returns the appropriate class or empty string :) Apr 28 14:02:50 but I don't want to explicitly encode the "fitimage" and "uimage" string into kernel.bbclass to make this process automated, so that whoever adds another image type doesn't have to modify kernel.bbclass again Apr 28 14:03:24 ah, I see, well that does complicate matters Apr 28 14:03:47 bluelightning: would you rather suggest I go for the "simple" solution and encode the image names ? Apr 28 14:04:06 bluelightning: maybe the KISS principe would work here just fine Apr 28 14:04:38 well, I don't personally object to that but others may, I'm not sure Apr 28 14:05:27 I can imagine checking for bbclass existance would be rather nasty due to the layers and such Apr 28 14:05:31 zeddii: any opinions? (a link to the thread with a very small amount of context: http://lists.openembedded.org/pipermail/openembedded-core/2015-April/104233.html ) Apr 28 14:06:22 Marex: that's possible but I don't think it's something we'd want to start doing, since it's not a mechanism we have elsewhere so it wouldn't be necessarily expected behaviour Apr 28 14:06:52 correct, I combed through the tree to see if someone else is doing it, but I didn't fine anything like it Apr 28 14:07:13 I was surprised that Yocto doesn't have some kind of variable which contains all class names it has in the tree Apr 28 14:07:42 I think there was this __inherit_cache, but I doubt that's what I want Apr 28 14:17:44 * zeddii reads Apr 28 14:25:48 bluelightning, Marex: I'm still back to my question in the original thread. Outside of making the bbclass smaller, what is the technical gain from splitting the image support into named classes ? Apr 28 14:30:50 zeddii, should be a bit faster since the parsing in bitbake has less to parse if you only load the smaller classes Apr 28 14:36:58 zeddii: I don't remember I'm afraid, I've really only been on the periphery of the discussion Apr 28 14:40:01 morning Apr 28 14:40:54 zeddii: the reason for splitting is so that I can add fitImage support Apr 28 14:41:14 zeddii: the fitImage support adds a new .bbclass which is a bit heftier than uImage, so I dont want to put it into kernel.bbclass Apr 28 14:41:26 that'd be confusing and would make kernel.bbclass into a nasty chaos Apr 28 14:41:50 I work better with patches. Is there a series I can look at to see the scope ? Apr 28 14:42:29 but the same issues are still there, we need the existing layers to not break. Apr 28 14:44:08 zeddii: there is, but I reworked the series so that it won't break existing layers, I might as well repost it Apr 28 14:44:19 cool. Apr 28 14:44:22 zeddii: can you PM me your email address so I can put you on Cc please ? Apr 28 14:44:39 done Apr 28 14:45:34 zeddii: OK, I will perform one more test build and post it then Apr 28 14:45:39 zeddii: thanks! Apr 28 14:45:41 bluelightning: thanks ! Apr 28 14:58:30 Any objections to passing the do_package_qa CachedPath instance into the QAPATHTEST calls? seems silly not to, when we already have an instance, and some of the functions do end up doing os.stat or os.path.exists Apr 28 14:59:03 so tired this morning Apr 28 15:18:08 zeddii: I promise I'll send you soon some text about initramfs-nightmare ;) Apr 28 15:19:31 ant_work, cool. I'm documenting and re-working where appropriate for the yocto 1.9 release. Apr 28 15:19:38 hmm. Apr 28 15:20:37 zeddii: atm the original how-to has been lost in internet meanders... Apr 28 15:21:01 anonymized! Apr 28 15:21:33 actually the hosting site is down :/ Apr 28 15:24:41 keyword was "linux-yocto-tiny as base for the creation of a kernel with embedded initramfs-kexecboot" Apr 28 15:29:18 I do not get how I can manually unpack this file generated by yocto: git2_git.kernel.org.pub.scm.linux.kernel.git.stable.linux-stable.git.tar.gz Apr 28 16:38:50 zeddii: patches are out Apr 28 16:46:57 Can anyone help me understand why I can't add the avahi package to my image? I get this error: " * opkg_install_cmd: Cannot install package avahi.". When looking at the logs, the opkg-cl command fails with code 255, and later when installing packages on root, it says "Unknown package 'avahi'." Apr 28 16:47:33 There is a recipe for avahi and it seems to be working correctly. I can't understand why it couldn't add it to the image Apr 28 16:54:57 DS_: with the way that recipe is packaged, there is no package produced called "avahi" Apr 28 16:55:32 DS_: there is however avahi-daemon and various other packages Apr 28 16:55:48 I'm guessing you probably want avahi-daemon Apr 28 16:56:58 bluelightning Yes, I want avahi-daemon. I don't understand how this packaging thing works, so I'd appreciate if you could explain it to me. What happens when I add only the "avahi" package? There is a recipe for it, so I assumed it would generate a package. Apr 28 16:58:21 DS_: typically recipes have ${PN} in their PACKAGES value, where ${PN} evaluates to the recipe name, thus it is expected that they produce a package named the same as the recipe Apr 28 16:59:01 the avahi recipe is somewhat special, it does have ${PN} in PACKAGES but the ${PN} package ends up empty and thus isn't actually produced, leading to the error you received Apr 28 16:59:50 most recipes do not work this way however Apr 28 17:00:24 Got it. Indeed it seems to be a special behavior. Thanks for the clarification Apr 28 17:00:45 By the way, adding avahi-daemon worked! Thanks Apr 28 18:31:33 I'm trying to build my custom image based on core-image-base.bb. It works fine with dizzy but when i build it with fido create_image.sdcard fails: 'tmp/deploy/images/cubox-i/SPL': No such file or directory Apr 28 18:34:16 Any thoughts what could cause that error? Apr 28 20:36:14 is it possible to exclude recipes to not be built on an image ? Apr 28 20:40:34 PACKAGE_EXCLUDE = "...." Apr 28 20:41:43 e.g. I hate busybox (I'm ok with the concept, I just hate having to _use_ the crippled thing) -- anyways, I've got: Apr 28 20:41:47 PACKAGE_EXCLUDE = "busybox busybox-dev busybox-udhcpc busybox-dbg busybox-ptest busybox-udhcpd busybox-hwclock busybox-syslog" Apr 28 20:47:49 paulg_, but with PACKAGE_EXLUCDE, would it be built ? Apr 28 20:48:11 i'm mean.. they will build the package but it wont be shipped Apr 28 20:55:07 might be... but unless it takes hours to build, then really the image is what you care about, no? Apr 28 20:57:54 the only alternative would be to figure out what's pulling it in and remove it there Apr 28 20:58:03 e.g. from the packagegroup, or IMAGE_INSTALL Apr 28 20:59:12 kergoth, i see Apr 28 20:59:13 thanks :) Apr 28 20:59:26 paulg_, yes it is to built it faster Apr 28 20:59:37 that might be trivial (e.g. right in the image recipe) or less so, depends Apr 28 21:10:23 kergoth, yeap... i'm using core-image-minimal but, there tons of things i don't want. It would be great with we can make like a blacklist so yocto wouldn't build it or, I can make a custom image Apr 28 21:10:44 i'd say just make a custom image, personally. if you know just what you want.. Apr 28 21:11:25 can also try a distro that doesn't support as much (via DISTRO_FEATURES, e.g. bluetooth), if you don't need to support those things Apr 28 21:16:00 realBigfoot, have you considered trying poky-tiny with core-image-minimal? Apr 28 21:16:07 shrinks things considerbly Apr 28 21:16:55 yeah, good idea Apr 28 21:17:13 there are lots of ways to trim things down depending on your needs Apr 28 21:18:23 dvhart, I haven't considered using poky-tiny actually... I will try it Apr 28 21:18:42 poky-tiny tries to start with almost nothing Apr 28 21:18:54 so it's an add-what-you-need instead of a remove-what-you-don't Apr 28 21:18:59 it's easier to add IMHO Apr 28 21:19:12 so plan on copying poky-tiny to realBigfoot.conf Apr 28 21:19:13 dvhart, nice... this is perfect Apr 28 21:19:37 great Apr 28 21:19:52 dvhart, yeap... ty Apr 28 22:44:44 * mranostay hides from dvhart Apr 28 22:55:14 Darren has a very special set of skills ; he will track you down and he will find you. **** ENDING LOGGING AT Wed Apr 29 02:59:59 2015