**** BEGIN LOGGING AT Fri Jul 05 02:59:58 2013 Jul 05 08:39:53 (xpost from #oe) Hello. I am having a little issue with bitbake. I have created a number of recipes, and now my system images depends on some of them. However, in spite of a certain package installing and compiling (in bitbake) without error, it does not seem to be made part of the final installation. During install it reports that Files/directories were installed but not shipped. I am using a Build script that came with this software, and it Jul 05 08:39:53 installs into D. What should I look at next? Jul 05 08:42:42 stygia: take a look at the FILES bitbake variable Jul 05 08:43:45 zibri, Hmm. So I should list all files it installs in this variable? Jul 05 08:44:58 zibri, The poky handbook seems to not provide much more information about it. Jul 05 08:46:11 stygia: bitbake.conf comes with some default patterns, like /usr/bin/*, but if your package installs to other, more unusual places, you have to list them. E.g. FILES_${PN} = "/opt/foo/*" Jul 05 08:47:09 stygia: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-FILES Jul 05 08:51:01 zibri, Thank you. It's hard to find good documentation for bb imho. Jul 05 08:59:16 zibri, Hmm. I have FILES_${PN} += "${libdir}/perl5" in my script, and yet, /lib/perl5 and several sublocations are shown as "installed but not shipped". Any suggestions? Jul 05 09:03:01 stygia: ${libdir} is /usr/lib, not /lib. Jul 05 09:08:00 zibri, Oh. What is /lib, then? Jul 05 09:11:18 Stygia: /lib -> {base_libdir} Jul 05 09:11:26 most defines are in meta/conf/bitbake.conf Jul 05 09:11:50 ndec, Ah awesome, duly noted. Was looking at the online documentation which is kinda lacking. I'll look there next time. Jul 05 09:17:21 morning all Jul 05 09:17:30 probably about time we had those in the manual I guess Jul 05 09:45:38 Hi guys, I'm using a custom rootfs recipe based on conf/distro/poky.conf. I need few apps like: bluez4, rfkill, hostapd, whole wireless-tools suite. I know I can specify all of them in IMAGE_INSTALL variable. But isn't is more Yocto'ier way to put something like 'wifi' to DISTRO_FEATURES ? Jul 05 09:50:58 Krz: if you include packagegroup-base in your image you will get something like that Jul 05 10:05:08 bluelighting: isn't packagegroup-base included by default in poky.conf? Jul 05 10:09:07 Krz: if your image inherits core-image and does not set IMAGE_INSTALL (but may add/append to it after the "inherit core-image") Jul 05 10:09:18 then it will include packagegroup-base yes Jul 05 10:10:49 bluelightning: ok I do set IMAGE_INSTALL in my rootfs recipe as: IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}" Jul 05 10:11:15 Krz: right, in which case you won't have it Jul 05 10:11:21 Krz: you can just add it to the end Jul 05 10:11:46 is there any list of what contents package-group base gives? Jul 05 10:13:54 Krz: only in the file itself: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/packagegroups/packagegroup-base.bb?h=dylan Jul 05 10:18:39 bluelightning: so I need to add packagegroup-base to IMAGE_INSTALL. What about MACHINE_FEATURES ? So far my MACHINE_FEATURES = "efi". Don't I have add there 'bluetooth' and 'wifi' ? Jul 05 10:20:39 Krz: if the platform has those features built-in, yes you should add those Jul 05 10:30:04 bluelightning: the platform does not have these features built-in. There are USB/PCIe ports where people can attach these kind of devices, so I just want to enable this kind of usage. Jul 05 10:34:04 Krz: ah ok... if you look at packagegroup-base you'll see it does have functionality to enable those features if the machine has usb/pci in MACHINE_FEATURES Jul 05 10:34:21 Krz: so you should probably just add "usb" and "pci" to MACHINE_FEATURES Jul 05 10:39:21 hi, getting this error when trying to use yocto: http://paste.kde.org/~lpapp/789782/ Jul 05 10:39:31 archlinux... I already reverted to python 2. Jul 05 10:40:04 this error message is there at the end, too: http://paste.kde.org/~lpapp/789788/ Jul 05 10:40:44 the second issue is probably easy to be fixed. Jul 05 10:42:06 WARNING: Host distribution could not be determined; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Jul 05 10:44:13 fixed the first issue, but getting new ones Jul 05 10:44:19 lpapp: I have been using Arch Linux for Yocto successfully. do you have lsb-release package installed? Jul 05 10:44:36 lsb-release shouldn't be required Jul 05 10:44:56 Net147: no, I will. Jul 05 10:45:05 bluelightning: I think he just means, the warning can be eliminated that way. Jul 05 10:45:13 I don't think it can Jul 05 10:45:28 WARNING: Host distribution ""Arch Linux"" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Jul 05 10:45:38 it is at least more to the point now. :) Jul 05 10:45:40 you can remove the "untested distro" warning by setting SANITY_TESTED_DISTROS = "" in your local.conf Jul 05 10:45:53 ERROR: Function failed: do_compile (see /home/lpapp/Projects/polatis/Yocto/poky-denzil-7.0.1/polatis-builds/tmp/work/x86_64-linux/m4-native-1.4.16-r2/temp/log.do_compile.11365 for further information) Jul 05 10:45:57 ERROR: Logfile of failure stored in: /home/lpapp/Projects/polatis/Yocto/poky-denzil-7.0.1/polatis-builds/tmp/work/x86_64-linux/m4-native-1.4.16-r2/temp/log.do_compile.11365 Jul 05 10:46:59 lpapp: you will probably have better luck with master branch of poky repository Jul 05 10:47:17 lpapp: I did many fixes for building on Arch there Jul 05 10:47:17 Net147: we do not use the master branch as we have a product on it ... Jul 05 10:47:25 and it is not just a matter of hobby updating to the bleeding edge. Jul 05 10:47:33 lpapp: then I'd suggest not using Arch in that case Jul 05 10:47:42 lpapp: ok. I recommend you use an official supported distro in that case Jul 05 10:47:51 or fix stuff my self. Jul 05 10:48:02 which looks more reasonable IMHO. Jul 05 10:48:17 lpapp: you can look in the poky master for additional patches you might need Jul 05 10:48:45 lpapp: it's entirely up to you of course, but if you're talking about ensuring stability for a commercial product you'd be better off with a stable host distro... Jul 05 10:49:11 bluelightning: how can you say that when you do not even understand the impact? Jul 05 10:50:41 lpapp: on the one hand you're saying you need to be using an older version of our build system for your product, I accept that and we definitely support that Jul 05 10:50:58 lpapp: but then you're trying to use it on one of the most bleeding edge distros that exists Jul 05 10:51:12 those two things do not really match up Jul 05 10:51:30 bluelightning: how can you say that when you do not even understand the impact? Jul 05 10:51:38 impact of what? Jul 05 10:51:44 the issues on arch? Jul 05 10:52:08 the issues on arch are due to newer host tools and libraries Jul 05 10:52:25 again, how do you know the impact for *sure*? Jul 05 10:52:42 have you tried? Can you enumerate them? How can you tell me it is less work to complicate the system with two distribution? Jul 05 10:52:45 mind elaborating? Jul 05 10:53:31 I can tell you I know things work fine on more stable distributions because I use the system daily on those distributions without issue... Jul 05 10:53:54 so what ? Jul 05 10:54:21 that does not tell me at all which is less work to go for ... Jul 05 10:54:45 so it is extremely brave to tell it is better to drop a corporate environment instantly and start setting up things from scratch. Jul 05 10:54:48 I would think it's fairly clear, if you want less work, follow the tested path that others have already followed Jul 05 10:55:03 fairly clear based on *what*? Jul 05 10:55:14 your imagination without knowing whether it is a two minutes fix, or less than an hour etc? Jul 05 10:55:18 based on others experience and our QA testing Jul 05 10:55:36 11:51 < lpapp> have you tried? Can you enumerate them? How can you tell me it is less work to complicate the system with two distribution? Jul 05 10:55:39 11:51 < lpapp> mind elaborating? Jul 05 10:55:51 lpapp: the simple fact is that if you're running a bleeding-edge distribution, you'll hit problems like a new host gcc breaking the build of the cross-compiler first Jul 05 10:55:52 could you please enumerate the issues on arch? Jul 05 10:55:53 have I tried running builds regularly on Arch? no I have not Jul 05 10:55:57 and why it is complex to fix them? Jul 05 10:56:21 rburton: how do you *really* know? Jul 05 10:56:28 how is this a "simple fact"? Jul 05 10:56:52 lpapp: because every new gcc release breaks something? because gnu make 3.82 *still* isn't fixed unless you grab patches from upstream? Jul 05 10:57:22 "because every new gcc release breaks something?" -> you live in a different world than me , then. Jul 05 10:57:23 rburton: lpapp: Arch has integrated the fixes required for make recently Jul 05 10:57:25 this isn't something to debate. if you consider that an acceptable compromise to running your distro of choice, then sure. Jul 05 10:57:42 rburton: you are totally wrong. Jul 05 10:57:43 Net147: i'm not saying it hasn't, i'm just saying thats an example of something that breaks if you run a bleeding distro. Jul 05 10:58:17 "is not fixed" -> is fixed. Jul 05 10:58:32 i wasn't talking about arch, i was talking about make Jul 05 10:58:41 there is not a make 3.83. that is a fact. Jul 05 10:59:15 lpapp: if you want to run the system on Arch, then more power to you Jul 05 10:59:26 my point was a bleeding distro will do something like integrate make 3.82 and then you've got the fallout of that to handle. as i said, if that's a trade-off you want to make, sure. Jul 05 10:59:27 lpapp: but to be crystal clear, whilst we are happy to take patches for support on Arch, and have done so regularly, we officially do not support that distro and we especially do not support latest Arch with older versions of the build system Jul 05 10:59:31 rburton: we *were* talking about Arch. Jul 05 10:59:38 lpapp: sure, and i was generalising Jul 05 10:59:44 so if you do not, it is kinda off-topic for a heavily arch based discussion. :) Jul 05 11:00:10 i run debian unstable on my machines so also get the fun of discovering breakage, but that's kinda my job Jul 05 11:00:56 guys, please try to accept that, setting up a brand new distribution from scratch, and get used to a different workflow is not a 2 miuntes job. Jul 05 11:00:59 minutes* Jul 05 11:01:09 lpapp: nobody said it was Jul 05 11:01:21 besides, it is also more useful for the world if yocto is tested on arch by other users as well. Jul 05 11:01:24 in my book, that is. Jul 05 11:01:27 sure Jul 05 11:01:51 lpapp: but backporting patches for support for versions of tools in the latest version of Arch (which we do seem to have) to an older branch will not be a 2 minute job either Jul 05 11:02:09 the caveat is that stable releases of yocto are not constantly tested on arch, so you may discover breakage. as i said, it's a tradeoff. Jul 05 11:02:26 besides, arch is a really a very common distribution Jul 05 11:02:46 sure Jul 05 11:03:46 almost the same amount of users on irc than in #ubuntu Jul 05 11:04:17 bluelightning: it is not even sure I need to backport any patches. Jul 05 11:04:24 lpapp: in my experience with Yocto on Arch, problems have been related to Python 3 being default, GCC 4.8, gets being removed from glibc, pod2man failing to build some docs with newer pod2man included with Perl 5.18, some texi documentation failing to build. that's with poky master branch, for denzil there are probably some more things that need to be patched Jul 05 11:04:24 bluelightning: what if I experience different issues? Jul 05 11:04:25 nobody's hating on arch specifically, just pointing out the tradeoffs between stable and unstable host distros Jul 05 11:04:37 bluelightning: you seem to claim things without investigation. Jul 05 11:05:10 lpapp: no, I go by reports and patches from folks such as Net147 who are building on top of Arch Jul 05 11:05:38 so others cannot experience other issues? Jul 05 11:06:16 all I am saying, it needs investigation Jul 05 11:06:25 it is really hard to tell IMO in advance which is more effort to go for. Jul 05 11:06:45 Net147: thank you for the information. :-) Jul 05 11:07:05 lpapp: sure, and you're more than welcome to continue to report issues here Jul 05 11:07:31 python 3 is not fixed in master though. :-) Jul 05 11:07:31 lpapp: as long as you are aware that our limited resources may not allow everyone to investigate those issues if they are host-related Jul 05 11:07:42 so that is not yet a reason to change distro. Jul 05 11:07:52 lpapp: python 3 support is a work in progress Jul 05 11:07:57 lpapp: for documentation fixes I had to do, refer to http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8144e16097fae49288d763d05476c892c46136c3 and http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=ea886ed79d7f10d2f8392398e65138f5da04a892 Jul 05 11:09:07 first issue: http://paste.kde.org/~lpapp/789824/ Jul 05 11:09:14 bluelightning: yes, so not yet fixed. :) Jul 05 11:09:28 and even if it was, it is simple enough on arch to fall back to python 2. Jul 05 11:09:53 Net147: cannot the doc be optional? Jul 05 11:10:18 lpapp: sure, but it's not really a bug fix situation, porting a codebase such as ours to python 3 is difficult; and as you say there is a workaround available Jul 05 11:10:21 it is not something I would desperately need on the embedded board ... Jul 05 11:10:30 lpapp: I was building docs for my dev image. it may not be needed in your case Jul 05 11:11:10 https://dev.openwrt.org/ticket/12005 -> this is a change in the openwrt project. Jul 05 11:11:16 re: my kde paste above. Jul 05 11:11:41 Net147: ok, thank you for the information. I am happy to exclude the docs. Jul 05 11:11:51 in fact, we should probably do that on the embedded board if it is not yet done. Jul 05 11:11:52 lpapp: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/m4/?id=19875a0f71b79bc3f3bb85c925ad103e6fe30641 Jul 05 11:13:14 Net147: thanks, so I need to learn how to patch stuff locally. Jul 05 11:13:25 I guess my ubuntu based colleagues would not mind arch fixes in our repo. Jul 05 11:15:38 Net147: do I understand correctly you had python 3 and documentation issues, nothing else? Jul 05 11:16:03 and gcc 4.8 Jul 05 11:16:24 and this glibc. Jul 05 11:17:32 lpapp: yes, but I was working with master branch not denzil Jul 05 11:17:43 well, the glibc should not be a problem in master. Jul 05 11:18:04 lpapp: yes it was already fixed when I began working with Yocto this year again Jul 05 11:18:17 lpapp: but I remember the gets issue from last year I think Jul 05 11:19:48 lpapp: as for GCC 4.8, there was a problem building GCC 4.7 using it so I had to install an older GCC on Arch and prepend it to PATH Jul 05 11:20:10 interesting. Jul 05 11:20:14 lpapp: I installed GCC 4.6.x from AUR to work around it Jul 05 11:20:21 how seamless is it to upgrade poky btw? Jul 05 11:20:27 lpapp: and created symbolic links for gcc, ld, etc. Jul 05 11:20:36 gah Jul 05 11:20:43 you had fun there... ;-) Jul 05 11:21:04 ah yeah, 4.8 can't build 4.7. good work gcc team. Jul 05 11:22:06 lpapp: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/gcc?id=3681c89432b5fb705fe593e75c2d98f7d15a5184 Jul 05 11:22:34 lpapp: that should allow you to build GCC 4.7 Jul 05 11:22:55 yeah Jul 05 11:23:07 is there a guide somewhere how to create patches for poky locally? Jul 05 11:23:16 is there any poky specific to it? Jul 05 11:23:34 lpapp: you want to add patch without modifying poky? Jul 05 11:23:49 lpapp: you generally create a bbappend in your layer directory Jul 05 11:24:07 yeah, local patches just like when you do distro packaging. Jul 05 11:24:23 and update/remove those when a new "package" update happens. Jul 05 11:26:01 lpapp: http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#using-bbappend-files Jul 05 11:27:42 Net147: I see... so everything \*.bbappend in our repository is probably our local patches, right, not coming from the Yocto project? Jul 05 11:28:23 lpapp: Yocto project core recipes are in meta directory, you usually have meta-mylayer or something with your own recipes and bbappends Jul 05 11:28:54 lpapp: and this meta-mylayer is listed in build/conf/layers.conf Jul 05 11:29:22 lpapp: * conf/bblayers.conf Jul 05 11:29:30 Net147: have these, find ./ -name \*.bbappend | curlpaste Jul 05 11:29:31 http://codepad.org/q6A5lWih Jul 05 11:29:56 I am just wondering if my team had already made local changes, and I am not introducing anything new with arch fixes. Jul 05 11:30:58 Net147: http://paste.kde.org/~lpapp/789836/ Jul 05 11:32:08 lpapp: meta-yocto looks like http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto?h=denzil to me Jul 05 11:32:58 ok, so probably not. Jul 05 11:33:41 that is bad because it means then, I introduce a new concept. :) Jul 05 11:33:46 probably harder to sell. Jul 05 11:34:53 where is your stuff then? in meta directly? Jul 05 11:35:31 lpapp: any other meta-* folders? Jul 05 11:35:48 Net147: no clue Jul 05 11:36:05 lpapp: ls poky-denzil-7.0.1/ Jul 05 11:36:16 Net147: sorry, but I cannot share company details. Jul 05 11:36:22 and I have no clue which are the default. Jul 05 11:36:22 if your stuff is in meta/ then i recommend you put it in your own layer so you can upgrade poky later Jul 05 11:36:47 lpapp: while i understand why you could be interested to keep Arch on your host, i think there are various methods that are very resaonable like building in a chroot, or VM, see http://bec-systems.com/site/1029/os-containers-for-build-systems. Jul 05 11:37:13 lpapp: poky-denzil-7.0.1 contains any other meta-* folders besides meta and meta-yocto? Jul 05 11:37:44 I assume meta-demoapps was coming with denzil. Jul 05 11:38:07 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/?h=denzil -> yes, it was. Jul 05 11:38:12 so we do not have any additional meta folder. Jul 05 11:38:29 ndec: thanks, but I am aware of chroot, and VM Jul 05 11:38:34 that was not the question. Jul 05 11:38:59 Net147: so, no, I do not have any custom meta folder. Jul 05 11:39:14 only the usual "meta meta-demoapps meta-hob meta-skeleton meta-yocto" Jul 05 11:39:21 Quite nice tutorial for newbies like me http://www.cnx-software.com/2013/07/05/12mb-minimal-image-for-raspberry-pi-using-the-yocto-project/ Jul 05 11:39:46 Net147: does that mean we use poky vanilla? Jul 05 11:40:36 ndec: usually when you have a problem, and you wanna solve it with VM, you have got two, IMO. Jul 05 11:40:58 and chroot is obviously not a solution for a full-blown ubuntu. Jul 05 11:41:24 lpapp: well... i mentioned VM, but really what i would recommend is chroot or container. Jul 05 11:41:27 lpapp: download denzil 7.0.1 and compare your tree to check Jul 05 11:42:06 ok, so there is no guarantee just yet. Jul 05 11:42:31 i actually quite like to be able to do all my builds in a container, and not 'touch' anything on my main machine. Jul 05 11:43:57 ndec: IMO, having a full blown second layer (new environment) instead of a few patches is an overly overkill. Jul 05 11:44:17 ndec: i'm lucky enough to have a dedicated build machine here, so that only has the barest system to get a build going. host contamination sucks. Jul 05 11:44:37 ndec: if i had to use a single machine, i'd certainly be running yocto inside a container of some sort for that. Jul 05 11:44:54 I use a VM for my build system Jul 05 11:44:57 lpapp: but by running after Arch, you might be running after something that runs faster than you.. Jul 05 11:45:13 it depends if you care about fixing OE, or using it, in fact. Jul 05 11:45:18 ndec: I run Arch for my Yocto builds =) Jul 05 11:45:33 ndec: but I am prepared to fix any issues that occur Jul 05 11:45:45 ndec: you are not obliged to update arch every single minute ... Jul 05 11:45:48 sure... you can .. but you can't guarantee that every morning when you wake up everything is just going to be fine ;_) Jul 05 11:45:59 yes, you can. Jul 05 11:46:46 anyways.. i didn't want to restart the discussion, it was a great time reading the backlog already, and we don't need more i guess! i just wanted to mention chroot/LXC as it hadn't been mentioned ;_) Jul 05 11:47:09 Net147: we actually have one "builds" folder in the poky root Jul 05 11:47:19 it contains conf/local.conf Jul 05 11:47:31 and downloads with many "\*.done" files Jul 05 11:47:53 that folder is used like this: Jul 05 11:47:56 . oe-init-build-env mybuild Jul 05 11:48:02 bitbake core-image-minimal Jul 05 11:48:05 is that ok? Jul 05 11:48:57 lpapp: that creates mybuild directory with a default conf/local.conf Jul 05 11:49:05 lpapp: and sets up environment for build Jul 05 11:49:35 well, it is checked into the repository, still. Jul 05 11:49:42 lpapp: you can compare default local.conf with the local.conf used in your repository Jul 05 11:50:00 so I do not think it is the default. Jul 05 11:50:22 lpapp: repository history should indicate if there have been changes to the file Jul 05 11:50:24 it's best not to check in a local.conf, if you want a site-wide conf file then you can check in site.conf Jul 05 11:50:24 in fact, I can say for sure it is not the default. Jul 05 11:50:38 local.conf should truly be personal configuration realy Jul 05 11:50:51 it is truly personal. Jul 05 11:57:27 lpapp: you could always just create your own meta-fixes layer and only add it to bblayers.conf when building on Arch Jul 05 11:58:08 yes, but it is not a simple sell as written when it is a bit more than what my colleagues has done so far. Jul 05 11:59:00 lpapp: are your target clients using Arch? Jul 05 11:59:22 Net147: pardon? Jul 05 11:59:40 lpapp: is Arch support important to your clients? Jul 05 12:00:08 Net147: I am not sure I follow. Jul 05 12:00:17 how is my host OS to relevant to the client of the embedded hardware? Jul 05 12:00:23 OS relevant* Jul 05 12:01:02 lpapp: is anyone else interested in building your project with Arch besides you? Jul 05 12:01:30 who knows Jul 05 12:01:34 but it is irrelevant to clients. Jul 05 12:01:53 I see Jul 05 12:02:25 why so weird questions, anyway? :) Jul 05 12:03:53 lpapp: anything else? Jul 05 12:04:41 Net147: hmm? Jul 05 12:05:19 lpapp: do you have any more questions? Jul 05 12:05:50 Net147: plenty. :) Jul 05 12:05:56 but I do not think it is Yocto related now. Jul 05 12:06:06 okay, elsewhere then Jul 05 12:06:06 I am getting rid of Yocto for the time being. Jul 05 12:06:18 and just trying to grab and build the kernel, only. Jul 05 12:07:31 lpapp: good luck =) Jul 05 12:08:36 Net147: thank you for the help. I am sure I will have questions later. Jul 05 12:08:45 But I asked a question above which got unanswered. Jul 05 12:09:15 lpapp: could you please repeat the unanswered question? Jul 05 12:09:19 12:19 < lpapp> how seamless is it to upgrade poky btw? Jul 05 12:11:21 lpapp: extract a new version and then copy your build/conf files and any of your other changes over Jul 05 12:12:01 lpapp: some version numbers may need to be bumped Jul 05 12:12:39 lpapp: it also depends whether your hardware is supported by the new version Jul 05 12:12:58 top tip is to use git branches instead of tarballs for poky, so you can checkout/branch/etc Jul 05 12:13:21 lpapp: personally I use a git clone of poky and then I have git clones for my project inside that poky folder Jul 05 12:13:36 Net147: as evil as they are, submodules are really useful there Jul 05 12:14:06 rburton: I haven't got into submodules yet Jul 05 12:15:06 Net147: guacamayo has a meta-guacamayo repo with submodules for all of the other layers. works nicely as the submodules are versioned along with our metadata, so changing branch means you get the right layer versions too. Jul 05 12:15:08 Net147: made the "port to master" work a lot easier Jul 05 12:16:03 rburton: perhaps something to read into later Jul 05 12:17:42 rburton: I use git format-patch | gzip | base64, base64 -d | gzip -d | git am to transfer git changes between computers =P Jul 05 12:32:12 can I share multiple DL_DIR ? or is there a way to cache part of it contents ? Jul 05 12:33:16 tinti: for multiple machines, you can copy DL_DIR to a shared location and use INHERIT += "own-mirrors" and SOURCE_MIRROR_URL to point to it Jul 05 12:33:27 tinti: for different build dirs on the same machine you can just share the same DL_DIR Jul 05 12:34:27 bluelightning: thanks, so I can do like DL_DIR=xpto . ov-setup build Jul 05 12:35:14 tinti: that works yes, or set it in local.conf or site.conf Jul 05 12:35:22 (or auto.conf for an autobuilder) Jul 05 12:35:59 still a bit newbie, for the first option which files would I edit? Jul 05 12:52:48 tinti: conf/local.conf under your build dir is the best starting point Jul 05 12:52:48 tinti: actually I don't think your above example will work Jul 05 12:52:49 tinti: if you did want to specify it on the command line it would have to be when you run bitbake rather than the setup script Jul 05 12:52:49 specifying it in local.conf is probably the easiest option Jul 05 13:39:03 anyone else getting "/usr/lib/libstdc++.so: could not read symbols: File in wrong format" when building GCC 4.8 package for target? https://bugzilla.yoctoproject.org/show_bug.cgi?id=4789 Jul 05 13:39:03 Bug 4789: normal, Undecided, ---, raj.khem, NEW , can't build gcc recipe - /usr/lib/libstdc++.so: could not read symbols: File in wrong format Jul 05 13:42:31 building GCC 4.7 works fine Jul 05 14:26:22 Hi, I want to know more about getting professional support? Jul 05 14:27:26 Crofton: this may be your queue :) Jul 05 14:27:28 er Jul 05 14:27:29 cue Jul 05 14:28:44 :) Jul 05 14:29:25 I can't find much official documentation about it, but I did hear it in the "getting started" training video :) Jul 05 14:32:10 fenrig: there are numerous smaller consultancies for bespoke stuff, or you can get a paid and supported version of yocto from a big vendor such as wind river/mentor/enea Jul 05 14:34:31 rburton: But I'll probably have to contact these companies so I they can inform me about it. The wind river websites doesn't really say anything about yocto support Jul 05 14:34:48 fenrig: the new wind river linux *is* yocto Jul 05 14:35:12 http://www.windriver.com/products/linux.html Jul 05 14:35:49 same for the larger companies, their tailored products are yocto-based Jul 05 14:37:57 Nice :D I'm actually just a student processing this information for a smaller companie (+- 50 employees) Jul 05 14:38:31 Is it advisable for a smaller company to pay for support? Jul 05 14:39:18 its the usual learn yourself vs pay someone to help Jul 05 14:39:44 fenrig: don't ask the cat about fish ;) Jul 05 14:39:54 it's certainly common for companies to contract a consultant for the harder stuff/advice Jul 05 14:40:04 * rburton can comment now that he isn't consulting anymore! Jul 05 14:41:39 a list of recommended freelance/consultant on yocto website, might be valuable. Jul 05 14:42:07 Well actually we are in learning it ourselves, it's actually a low level controller company. But they want to use Linux and probably Qt for smarter and more "sexy" HMI's Jul 05 14:42:39 ndec: yes, it would. but recommending is tricky. Jul 05 14:42:40 ndec: indeed, yocto doesn't provide much information about it :) Jul 05 14:42:55 rburton: also true :) Jul 05 14:43:00 rburton: agreed. in fact https://www.yoctoproject.org/ecosystem/yocto-project-participants is a decent 'starting' list. Jul 05 14:43:23 fenrig: one option is to mail the yocto list with a brief outline of the work and ask if anyone is interested Jul 05 14:44:00 or https://www.yoctoproject.org/ecosystem/member-organizations Jul 05 14:46:31 fenrig: honestly if time is not a matter and you're not using any fancy new hw you could reasonably do that yourself Jul 05 14:46:41 but if you have deadlines then... Jul 05 14:48:15 Well we are experimenting with the system as we speak :) Jul 05 14:48:21 so no deadline is not an issue :) Jul 05 14:49:06 no deadline sounds like a dream job ;-) Jul 05 14:49:06 We are even in the process of choosing decent hardware, at the moment we are thinking about emtrion because they have dimm baseboards :) Jul 05 14:50:41 ndec: I do have deadlines, but they are aggreed upon while the work is ongoing. We don't have much experience with linux embedded, but because it's such a blooming business (YOCTO is really a great build system) it isn't that complicated as it used to be :) Jul 05 15:38:56 Hello All, I am trying to do bitbake fsl-image-full but everytime I am running this command I am getting this error - ERROR: Task 674 (/home/lahar/QorIQ-SDK-V1.4-20130625-yocto/meta-fsl-ppc/recipes-devtools/qemu/qemu_fslgit.bb, do_install) failed with exit code '1'....Please help me with this.. Jul 05 15:39:32 bitbake fsl-image-minimal builds just fine...It's just the full image which is giving me errors. Jul 05 15:40:02 Lahar: read the actual log it points at to see what the actual error was Jul 05 15:42:00 rburton: Yes I tried to read and my guess is - It wasn't able to install qemu_fslgit.bb ? And I am not sure how to fix this? Jul 05 15:43:31 Lahar: can you pastebin the complete error? Jul 05 15:43:32 Lahar: pastebin the entire log.do_install Jul 05 15:47:58 Lahar: are you working off master or dylan? (or something else) Jul 05 15:49:38 rburton: bluelightning: I am runnning Linux on virtual machine and for some reason my virtual machine is not getting connected to internet and copy paste from there doesn't work...Trying to fix...will paste error soon.. Jul 05 15:51:01 tlwoerner: I am not sure what dylan and master is...I am using P4080DS board and dowanloaded installed v1.4 SDK. It's a freescale board and SDK. Is this is what you are asking? Jul 05 15:54:12 1.4 == dylan (http://wiki.yoctoproject.org/wiki/Releases) Jul 05 15:56:25 rburton: tlwoerner: rbuton, Thanks for the link. I am using Yocto 1.4 so that means yes I am using "Dylan" Jul 05 16:34:48 rburton: Here is the pastebin link - http://pastebin.com/MsNvXkM1 Sorry for late reply. Was having some technical issues. Jul 05 16:35:02 bluelightning: Here is the link - http://pastebin.com/MsNvXkM1 Jul 05 16:37:24 Lahar: I think this is something you'll need to post about on the meta-freescale mailing list: https://lists.yoctoproject.org/listinfo/meta-freescale Jul 05 16:37:49 since this is custom version of qemu from the meta-fsl-ppc layer Jul 05 16:38:04 bluelightning: ok Thanks! Really appreciate your help. Jul 05 16:38:24 (assuming there are no Freescale PPC experts in here at the moment that is...) Jul 05 16:39:05 bluelightning: how do we know what to post and where? Do I need to come here and ask first everytime I see something? Jul 05 16:40:05 Lahar: depends where the problem is... in this case I saw that it was qemu_fslgit that failed, and I knew that isn't something that is part of the core Jul 05 16:40:30 it's fine to ask any questions here as long as they are yocto-related; if there are better places we can always direct folks there Jul 05 16:40:44 bluelightning: got you! Thanks Jul 05 16:57:46 hmm... fail Jul 05 17:18:11 hi again... Jul 05 17:18:16 who is working on the python3 port? Jul 05 17:29:31 lpapp: Richard Purdie Jul 05 17:29:42 lpapp: he is on holiday at the moment however Jul 05 17:29:49 I would like to help. Jul 05 17:29:58 but some coordination would be inevitable. Jul 05 17:30:03 sure Jul 05 17:30:05 if he is on holiday ... not much that can be coordinated. Jul 05 17:30:30 I think we could still accept patches at this point as long as they do not break compatibility with 2.7 Jul 05 17:31:33 AIUI most of the changes left are of the nature that makes it hard to maintain backwards compatibility though Jul 05 17:33:35 the low-hanging fruit has been sorted afaik Jul 05 17:33:46 but grabbing the branch and making it actually work would be a good start Jul 05 17:33:53 iirc, it runs but doesnt build entirely correctly Jul 05 17:41:51 maybe we should convert to 3 and run 3to2 or something Jul 05 17:41:52 heh Jul 05 17:45:25 Apparently RP is having motorcycle issues Jul 05 17:45:48 Crofton|work: oh? Jul 05 17:46:06 (one might be tempted to ask "when is he not") ;) Jul 05 17:46:14 very true Jul 05 17:46:31 although given the punishment his bikes go through it's understandable Jul 05 17:46:33 especially since he rides it off road and falls off Jul 05 19:43:31 I could use some debugging help... I'm trying to build poky (dylan 9.0.1) with a beaglebone BSP (https://gitmeta-beagleboard). Jul 05 19:43:49 https://github.com/beagleboard/meta-beagleboard Jul 05 19:45:27 I build core-image-minimal and that works until the rootfs is to be populated. Jul 05 19:46:19 "Note: to be installed: rpm-postinsts@all packagegroup-core-boot@beaglebone" Jul 05 19:46:32 "Computing transaction...error: Can't install libblkid1-2.22.2-r3@armv7a_vfp_neon: no package provides libuuid1 >= 2.23.1" Jul 05 19:47:42 libuuid1 is built, but at version 2.22.2 Jul 05 19:48:44 How can I debug why this rpm-postinsts depends on version 2.23.1 due to switching BSP? Jul 05 21:00:15 Managed to work around by wiping the build directory and starting over again, just deleting build/tmp didn't help Jul 05 23:48:59 Anyone that may want to help me to change the OS of my TV? I have bootloader access. Jul 05 23:49:45 Uboot and Mstar followed by a Titania-CPU. **** ENDING LOGGING AT Sat Jul 06 02:59:58 2013