**** BEGIN LOGGING AT Thu Jun 23 02:59:57 2016 Jun 23 03:42:54 this is reproducible. if i bitbake -c clean systemtap; bitbake -C configure systemtap, bitbake re-runs 149 setscenes. packagedata for gcc-runtime-external, etc Jun 23 03:43:01 makes no sense Jun 23 03:46:34 kergoth: could you file a bug? Jun 23 03:46:39 (please) Jun 23 03:49:04 * kergoth adds to the list **** BEGIN LOGGING AT Thu Jun 23 04:34:29 2016 Jun 23 04:50:18 kergoth, thank you very much! Jun 23 04:50:36 ? Jun 23 04:50:55 c0rnel: also we already have a datetime variable. ${DATETIME} Jun 23 04:50:55 * kergoth yawns Jun 23 04:50:58 :) Jun 23 04:51:43 ~ 12 hours ago Jun 23 05:01:29 boucman_work, thank you Jun 23 05:09:40 ah :) Jun 23 05:09:41 np Jun 23 05:19:28 whenever i run $ bitbake my-image-definition, what is the variable holding "my-image-definition" ? Jun 23 05:33:08 it's not a variable, it's a recipe Jun 23 05:33:15 see the yocto project documentation at yoctoproject.org Jun 23 05:34:55 kergoth, i want to use it to create a deploy directory for each image i build Jun 23 05:35:17 oh, i see what you're asking Jun 23 05:35:20 you want IMAGE_NAME Jun 23 05:35:24 iirc, anyway Jun 23 05:35:33 i want the directory to be called $my-imgae-definition-${DATETIME} Jun 23 05:35:47 ok, i'll try it Jun 23 05:35:51 thank you kergoth Jun 23 09:05:11 good morning Jun 23 09:05:17 hi guys Jun 23 09:15:06 is there a way to have explicitely eth0, eth1 instead of having sit0/eno1 or something else, depending on the network card? I assume this is done by the linux kernel but not sure if i can avoid that Jun 23 09:24:40 lzo: I guess you could rename the network interfaces using udev rules Jun 23 09:25:17 lzo: you can edit /etc/udev/rules.d/70-persistent-net.rules so that a preferred persistent name is assigned Jun 23 09:31:29 frsc / mckoan : i tried to do it this way but looking at the 70-persistent-net.rules file existing in my host distribution, but it looks like this is automatically generated, so if edit it myself, i will probably have to know the ATTR{address} before building my image, considering i have several interfaces Jun 23 09:34:53 lzo: something like this should work without specifying the address: Jun 23 09:34:54 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="sit0", NAME="eth0" Jun 23 09:35:14 frsc: have a look at /lib/udev/write_net_rules Jun 23 09:38:16 yes, but it means that i have to know that the kernel interface name is "sit0" before generating the udev rule. Thus, no really need to have this kind of renaming because if i already know it'll be "sit0", i can directly update /etc/network/interface file accordingly, which is what i'm currently doing tbh Jun 23 09:54:43 lzo: ok, I got it. Don't really know how to handle this without changing the kernel then... Jun 23 10:19:48 frsc: yes, that's what i thought. Jun 23 11:00:59 welcome everyone Jun 23 11:25:19 hi. need a hint: Jun 23 11:26:09 can I have two versions of gcc installed in my sdk? Jun 23 11:26:15 i'm building a distro for beaglebone (actually beaglebone green wireless). all works except that on boot u-boot looks for am335x_boneblack.dtb, but my device tree has another name. Jun 23 11:26:47 what's the best way to handle that? as far as i can tell there are two ways: rename the device tree or include a uEnv.txt Jun 23 11:27:23 uEnv.txt seems to be the most flexible option, but I'm unsure where/in what recipe i should handle that Jun 23 11:27:40 optionally the uEnv.txt should be dynamically generated to use the same device tree as KERNEL_DEVICETREE Jun 23 11:27:48 if I've added opensftp-server to my image. what is the quickest way to test it? Jun 23 11:28:49 CTtpollard: sftp? Jun 23 11:29:18 rburton: openssh-sftp-server to be exact Jun 23 11:29:29 test it with the sftp client Jun 23 11:32:07 rburton: of course, Im just wondering what I need to add to sshd_config to confirm bitbake has configured it Jun 23 11:33:11 well if you added the package then it should be working Jun 23 11:33:32 totally the best way to test it is to try sftping in, then you check that its *actually* working Jun 23 11:35:51 I can see the lib is there under usr/lib/openssh/sftp-server, but no config set in sshd_config Jun 23 11:37:35 rburton: cool it's working, sftping directly to the host working by default :) Jun 23 11:37:46 thanks Jun 23 11:39:45 Got another idea: i could perhaps make am335x-bloneblack.dtb a symbolic link to the real dtb in do_install_append of the kernel recipe ... Jun 23 11:41:21 * pidge is going to do awful things to fetch2 in a few weeks. Jun 23 11:41:44 s3 fetcher. booo. Jun 23 11:54:12 anyone here has any experience with ofono? Jun 23 11:54:40 I tried the ofono IRC but no one is replying there :/ Jun 23 11:59:37 hi, I am getting a bitbake error due to lgplv3+ being an incompatible license of a depending recipe. how can I enable lgpl to be compatible with my own recipe? Jun 23 12:00:29 CoLa|work: somewhere you have INCOMPATIBLE_LICENSE set (usually used to exclude GPLv3 or other licensed code that you want to keep out of the target image) Jun 23 12:06:38 bluelightning: so I can only specify this for the complete bitbake build but not for single library/recipe combinations? Jun 23 12:07:23 CoLa|work: it' Jun 23 12:08:10 CoLa|work: it's not generally used on an individual recipe basis, it's a configuration-level switch - you specify the licenses you want to exclude Jun 23 12:08:32 s/generally/intended to be/ Jun 23 12:09:10 it seems to me either you want to exclude LGPLv3 or you don't Jun 23 12:09:34 if you still do, perhaps all you need to do is ensure you have an LGPLv2 (or other) licensed version of the recipe in question Jun 23 12:10:34 hmm, I was more thinking along the lines that I can combine a recipe for the closed source commercial package with a dynamically linked lgpl library Jun 23 12:11:29 that doesn't absolve you of abiding by the terms of the LGPL though Jun 23 12:11:46 hence the restriction... if you don't consider the restriction to be a concern, then just disable it completely Jun 23 12:15:13 bluelightning: grep just told me that INCOMPATIBLE_LICENSE is nowhere set, may it be that my recipe license "closed" be the problem then? although I am convinced that I am combining both correctly due to the LGPL terms Jun 23 12:15:39 it must be set or you would not receive that warning Jun 23 12:16:03 when you say grep did you check bitbake -e | grep ? Jun 23 12:16:08 have you checked local conf? Jun 23 12:16:40 * CoLa|work did: grep -nr INCOMPATIBLE_LICENSE Jun 23 12:17:02 I guess that must have missed a configuration file then Jun 23 12:17:04 or better, bitbake -e | less then search within that for it - then you see the history Jun 23 12:17:17 that will tell you exactly where it's set Jun 23 12:17:23 and the error was: ERROR: zeromq was skipped: incompatible with license LGPLv3+ Jun 23 12:17:42 yep, so INCOMPATIBLE_LICENSE must be set somewhere Jun 23 12:18:05 really the term "incompatible" is wrong, we should have named it "exclude" Jun 23 12:18:11 but anyway Jun 23 12:18:37 bluelightning: awesome, found that setting, thanks Jun 23 12:18:46 np Jun 23 12:21:00 arrrgghh!! Jun 23 12:21:07 nothing works. Jun 23 12:21:44 so. i want to link /boot/the-device-tree.dtb to /boot/am335x-boneblack.dtb as part of either install or package, whichever is most suitable. Jun 23 12:22:46 first i added: do ln -s ${D}/boot/the-device-tree.dtb ${D}/boot/am335x-boneblack.dtb, but then i got a warning that some installed files were not packaged, and i should add it to FILES Jun 23 12:23:02 so i added FILES_${PN} = "/boot/am335x-boneblack.dtb" Jun 23 12:23:09 but got the exact same error message Jun 23 12:23:39 then i tried to use do_package instead of do_install, but then i got a really bad error message.... Jun 23 12:24:07 any ideas? Jun 23 12:26:06 ionte: there is no ${PN} package by default for the kernel Jun 23 12:26:25 ionte: so I guess you'd need to pick a package that actually is in PACKAGES for the kernel recipe Jun 23 12:27:28 perhaps "kernel" or "kernel-base" Jun 23 12:27:57 uhm, ok, perhaps FILES_kernel-devicetree then? Jun 23 12:28:17 oh yes, that would be it Jun 23 12:28:34 I'd forgotten linux-dtb.inc adds a specific package for it Jun 23 12:29:12 somehow we should try to avoid people falling into this hole because you're by no means the first to do so Jun 23 12:29:51 bluelightning: good to hear, was pulling my hair there for a while :) Jun 23 12:41:51 kergoth: I did try that commandline you mentioned. Obviously if its going to rebuild systemtap it does need the kernel source and compiler and so on so its understandable that it installs some stuff from sstate. I did try it adding a "bitbake systemtap" first to account for the initial dependencies and it does only seem to rebuild systemtap. I don't doubt there is some issue there but we're going to need a more involved reproducer I think :( Jun 23 12:43:49 all: how do i disable cross-canadian toolchain generation for my sdk? Jun 23 12:50:12 How can I find the list of packages included in an image ? Jun 23 12:51:22 qt-x: next to the image in deploy is a manifest Jun 23 12:51:22 qt-x: read the manifest file? Jun 23 12:54:00 Great! Is there a way to view the dependencies tree ? Jun 23 12:58:01 qt-x: enable buildhistory and it produces a dependency graph file Jun 23 12:58:50 qt-x: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality Jun 23 13:35:36 hi, is it possible to set the version inside a recipe as opposed to include it into the recipes file name? Jun 23 13:39:17 mwarning: yes, many recipes do this Jun 23 13:39:28 how do they do that? Jun 23 13:39:53 set PV Jun 23 13:40:17 ah! :) Jun 23 13:59:38 rubdos, neverpanic, bluelightning: thanks Jun 23 14:00:03 rburton, thanks in qt-x's name :) Jun 23 14:01:16 :) Jun 23 14:11:31 hi, is there a variable like ${THISDIR} but which shows the directory of the current .bbappend file? Jun 23 14:11:58 i have some files I'd like to install, but I have no idea how to get to the directory of the .bbappend Jun 23 14:12:19 thisdir seems to point to the .bb file Jun 23 14:13:52 blotunga: Pretty sure THISDIR changes for a .bbappend. Jun 23 14:14:09 Our layer has, as example: python_2.7.11.bbappend:FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" Jun 23 14:14:12 stwcx: ok, let's try again then Jun 23 14:14:32 And then we have a patch file along side the bbappend Jun 23 14:14:50 Well, in python/ beside the bbappend, but same concept. Jun 23 14:15:28 hmm, in this case ${THISDIR} points to the .bb's dir Jun 23 14:15:44 or maybe that's because I use ${THISDIR} in the do_install()? Jun 23 14:16:00 Oh. Jun 23 14:16:22 You will want to append/prepend to the FILESEXTRASPATHS like the example I gave here. Jun 23 14:16:36 yepp, i did that Jun 23 14:17:09 You're trying to install a file from beside the bbappend into the package? So you have do_install_append() ? Jun 23 14:17:24 but in do_install_append() i tried something like install -D -p -m 755 ${THISDIR}/... ${D}/... Jun 23 14:18:37 I think you should reference ${WORKDIR} in that case. Jun 23 14:18:59 The files you want to install are added to SRC_URI, path added to FILESEXTRAPATHS, then the files get put into WORKDIR. Jun 23 14:19:18 ah Jun 23 14:19:37 https://github.com/openbmc/openbmc/blob/master/meta-phosphor/common/recipes-devtools/python/python_2.7.9.bbappend Jun 23 14:19:44 That is the example I am basing this statement on. Jun 23 14:19:48 I'm by no means an expert. Jun 23 14:19:59 First 4 lines in that file. ;) Jun 23 14:20:36 the issue is that there are a bunch of scripts Jun 23 14:20:46 and I don't want to name them all with file:// Jun 23 14:21:05 actually a bunch of subfolders with a bunch of scripts :( Jun 23 14:23:48 Can you get a wildcard that points to them all? I don't recall if you have to be explicit with SRC_URI or if you can do wildcards. Jun 23 14:24:26 Or, sort of a hack, but can you add a new variable MY_SCRIPTS_TO_INSTALL = "${THISDIR}/..." and then reference MY_SCRIPTS_TO_INSTALL in do_install_append? Jun 23 14:24:42 Obviously a poorly named variable. Jun 23 14:25:31 i have no idea if SRC_URI accepts wildcards... Jun 23 14:26:28 i could use something like file:///* then Jun 23 14:26:52 I have a feeling that it does not accept wildcards since it is a URI. Jun 23 14:28:37 it's interesting though not helpful in my case that you can use SRC_URI with a git repository... Jun 23 14:32:23 blotunga: That is often the "typical" SRC_URI. Jun 23 14:32:25 ;) Jun 23 14:32:30 yupp Jun 23 14:32:47 I am also not an expert, but I included a tar.gz file Jun 23 14:33:01 it untars it to the workdir Jun 23 14:33:37 I'll probably get kicked in the ass for saying it, but I prefer buildroot, somehow it has less hoops Jun 23 14:34:20 blotunga: might work for you? Jun 23 14:34:54 nillerbrun: not sure right now, as I planned including the scripts in the same repository where my .bbappend is Jun 23 14:35:21 and the scripts might change over time, binary files in a git repository are never a good idea Jun 23 14:35:28 or almost never Jun 23 14:36:15 For me this is just a local file ... SRC_URI = "file://images.tar.gz" Jun 23 14:36:59 blotunga: I've used both. buildroot has a lower barrier to entry but is less powerful. Jun 23 14:37:03 I also didn't want to single out every file in the SRC_URI statement. Jun 23 14:37:27 buildroot for instance doesn't have the "sstate" which can take a typical 1hr rebuild down to minutes. Jun 23 14:37:37 stwcx: as a developer I appreciate lower barrier of entry, less hoops to jump through to actually getting things done Jun 23 14:38:13 blotunga: Right. It is the difference between a developer for a single package vs the maintainer for a number of them. I have to do both. Jun 23 14:38:14 yeah, but buildroot has a great manual control over the build if you know what you need Jun 23 14:38:49 I maintain two different distributions. One that is bitbake based and one that is yocto based. Jun 23 14:38:55 I mean... one is buildroot based. Jun 23 14:39:32 right now I have to integrate our proprietary stuff in somebody else's proprietary stuff which uses yocto... ofc I know only about 5% of what they have there... Jun 23 14:39:53 :D Jun 23 14:40:01 the buildroot integration took me exactly 2 days Jun 23 14:40:21 the yocto one, albeit with a bit more third party stuff, is dragging along for weeks Jun 23 14:55:09 hi Jun 23 16:26:51 I want to include apt-get, gcc tools, and php with apache. I'm using toaster. What layers do I invoke? know that these are parts of openembedded layer and also meta-network, meta-webserver Jun 23 16:27:50 Anyone else out there? Jun 23 16:31:11 search the layer index. Jun 23 16:31:23 and this is irc, don't expect a response in less than a minute, that's ridiculous. Jun 23 16:31:35 irc is an async medium, half the people in here are likely elsewhere, idle, or doing their jobs Jun 23 16:37:06 or both! :P Jun 23 16:37:09 noted Jun 23 16:51:57 rburton: just grabbed a few commits from your fork of 'bb', thanks Jun 23 16:52:23 dmoseley: you too, thanks. your commit was quite similar to a fix done to the upstream 'sub' project which is where bb's structure came from, but glad to see it Jun 23 16:52:25 kergoth: yeah i meant to push those :) Jun 23 16:52:29 :) Jun 23 16:52:36 i fixed it for python 3 and the runqeueu changes last night Jun 23 16:53:18 and fixed the long standing whatdepends bug where it doesn't check all targets (that is, it might find recipes that depended on glibc but not virtual/libc if you specified 'glibc'), and fixed it to also check runtime dependees, finally Jun 23 16:53:21 that'd been bugging me for ages Jun 23 16:53:42 doesn't tell you *why* something was pulled in, still only says this recipe pulled in taht recipe, but not this package from this recipe pulled in that package from taht recipe, but it's a start Jun 23 17:22:04 I am still trying to incoporate a precompiled package (3rd party) into my image. I created a recipe for this package that just uses the cp command to copy the files into the destination file system, but I have multiple errors (QA and a "no package provides" error). I can disable the QA errors, but can't find a way to get around the no-package-provides error. Jun 23 17:23:19 Am I going about this the wrong way, is there a better way to incorporate prebuilt binaries and libraries into a yocto build? Jun 23 17:28:35 I see the layer index shows me that if I want the various features I should include openembedded-core. I have. Does that mean the build includes the "meta" subdirectory where all my stuff-of-interest resides? Jun 23 17:32:09 stumpy: if you mean bblayers.conf has ${OEROOT}/meta at the top, then yes Jun 23 17:32:56 you need to explicitly include */meta directory Jun 23 17:36:16 Hi, I would like to know if it is possible to make an image that supports both systemD and sysVinit init systems. Ideally, I would like to be able to switch between them by changing the /sbin/init symlink, or something comparable. Jun 23 17:41:52 but I'm running toaster. Doesn't Toaster maintain its own version of bblayers.conf? maybe this is the root of my problem Jun 23 17:54:49 stumpy, it might Jun 23 17:56:19 just grabbed yocto off git, not able to sustain build with toaster by calling out a stack of standard layers. Here's the error msg in toaster_ui.log... Jun 23 17:56:45 ....whoops. Take that last one back now it's running Jun 23 17:59:05 but it gets me back to the original question. Though I have openembedded-core called out as a layer in Toaster, can I be sure I get apt-get and gcc tools? If one looks into the layer spec, these recipes are buried under in subdirectories. I know that when I do a command line bitbake, I can dress up the bblayers.conf file to explicitly call for them. How is it that I do this in Toaster? read all the way through the manuals, can't Jun 23 18:04:07 stumpy: if you can build and there's a depend on a recipe in oe-core, it's working Jun 23 18:04:33 otherwise you would get a non-buildable error Jun 23 18:04:37 yeah as a matter of fact meta-oe shows up in the Layers list Jun 23 18:06:34 I have a build that completes and works. My issue is that I'd like to know that I'm getting the packages I need out of oe-core. Is that a function of the image recipe? Jun 23 18:07:01 more-or-less Jun 23 18:07:34 oe-core is sort of poky-without-bsp Jun 23 18:07:41 How can I guide the situation so that I get, for example, apt-get? anything I can do inside Toaster Jun 23 18:07:44 and without poky Jun 23 18:07:46 :) Jun 23 18:08:20 there are differences in recipes, but a lot of extra stuff comes out of meta-openembedded either way Jun 23 18:09:00 if you're using .debs then you better get apt-get... Jun 23 18:09:16 it should come with the package-management stuff Jun 23 18:09:52 yeah, I'd really like to have apt-get. Building right now with core-image-minimal. Not sure that it hooks the stuff I need. How to fix things so I get desired functions? Jun 23 18:10:28 Perhaps a way to copy off core-image-minimal and tool it a bit? open to suggestions, I'm real new at yocto Jun 23 18:11:38 There has to be an image recipe that turns up basic stuff like apt-get and gnu C/C++ toolchain. Looking high and low for that one Jun 23 18:12:48 And yes I have invested time browsing the image directory on toaster. Not enough explicit info to nail the choice Jun 23 18:40:21 Anyone know if bluelightning's changes to tinfoil to use the bitbake server ever got merged? Jun 23 18:45:18 looks like the answer is no Jun 23 18:55:46 anyone out there know of an image recipe that hooks apt-get? if not what document do I read to find out how to take, say for example, core-image-minimal and add apt-get to it? Jun 23 18:57:49 just change your packaging from ipk to deb, that'll take care of 90% of it Jun 23 18:58:09 then add package-management to IMAGE_FEATURES to make sure it get sincluded, since normally cor-eimage-minimal doesnt' include the package manage r(or use a differnet image) Jun 23 18:59:33 for anyone that might find it of interest, https://gist.github.com/kergoth/099f66cbd1cd13a26037742e487ff67b shows the new more useful behavior of the fixed/improved bb-whatdepends Jun 23 19:12:18 kergoth: those bb utilities could find its way to bitbake itself no? Jun 23 19:15:00 that's always been the goal, yeah. richard wants to see an interactive mode with commands of that sort, we just haven't gotten the details fleshed out, and there've always been higher priorities Jun 23 19:15:50 it's something i threw together on my own time, so not sure i could get mentor to let me spend much work time on it, so.. i am convinced a sub-command based UI would be superior to bitbake's current confusing combination of command-line arguments Jun 23 19:19:24 kergoth: we did the ye to fulfill part of the bitbake flaws Jun 23 19:19:34 kergoth: and we reused part of bb inside it as well Jun 23 19:19:49 kergoth: http://doc.ossystems.com.br/ye.html Jun 23 19:20:29 ah, yes, that is similar in some ways. more pattern oriented, and more interactive / prompting Jun 23 19:20:41 lots of useful stuff there Jun 23 19:20:56 kergoth: if you want, look at the source at: https://code.ossystems.com.br/gitweb?p=apps/ye.git;a=summary Jun 23 19:21:10 possibly something else would try to collaborate on submitting upstream, but i barely have the time to do anything with the setup scripts at this point, possibly at some point in the future Jun 23 19:21:14 heh Jun 23 19:21:39 yes; btw ... I made it work with py3 Jun 23 19:22:26 heh Jun 23 19:22:52 nice Jun 23 19:36:36 kergoth: have changed packaging to deb. Three questions: [A] does Toaster respond to changes in local.conf like cmd-line bitbake? [B] are you referring to EXTRA_IMAGE_FEATURES variable in local.conf? [C] if [B] == false, which file holds IMAGE_FEATURES variable for me to set? will grep for it... Jun 23 19:46:44 B would be fine, yes. and i have no idea on toaster, i think i've only ever used it once Jun 23 19:47:28 Looking in ../meta/conf/bitbake.conf, there's a line that says...'IMAGE_FEATURES += "${EXTRA_IMAGE_FEATURES}". Jun 23 19:48:50 kergoth: if line cited above is parsed after local.conf is processed, setting EXTRA_IMAGE_FEATURES = package-management does the trick, correct? Jun 23 19:53:59 Kergoth: read the manual, says that IMAGE_FEATURES gets set in the image file, yes? if so, any way to manage that from Toaster? Jun 23 19:54:18 EXTRA_IMAGE_FEATURES is included in IMAGE_FEATURES if set Jun 23 19:54:35 so yes, as you say, adding it to extra image features will be fine Jun 23 19:58:44 THX as always. Looking in the Yocto Dev. Manual (for those who may see this later) see sec 5.2.2. It's pretty well stated there Jun 23 19:59:46 Does setting stuff in local.conf propagate forward to Toaster? suspect so, I'm a newbie asking folks who've been at it a while... Jun 23 20:20:35 stumpy: AFAIK, depends on how you start the build - if it's via the command line absolutely, if it's from a project within the Toaster interface, no - in the latter case the configuration is specified in the project Jun 23 20:45:24 kergoth: glad to contribute here. There's a link to a "VARIABLES" page where the Toaster user can manually configure stuff Jun 23 20:46:41 checked the local.conf in ../build-toaster-2/conf/local.conf, it's all defaulted though I changed my ../bitbake/conf/local.conf Jun 23 20:47:01 Will try it the "VARIABLES" page way to see what happens Jun 23 22:01:32 how old and/or funky of a host toolchain is krogoth supposed to spport? Jun 23 22:02:02 ld.bfd works back to binutils 2.22 Jun 23 22:02:34 shouldn't he be using an older release branch or upgrade toolchain? Jun 23 22:17:25 seems 12.04 is not supported on 2.0 or higher Jun 23 22:20:20 12.04 is starting to get a little long in the tooth, i expect Jun 23 22:21:50 hello Jun 23 22:25:18 nerdboy: its supported Jun 23 22:25:33 or atleast we havent seen it being limited Jun 23 23:14:13 yocto 2.0 refman says 14.04 lts or higher Jun 23 23:14:34 * nerdboy thinks he just wants to see another round of patch spinning Jun 23 23:15:17 if it chokes on ld.bfd then i'd say "yes" to "is your linker broken?" Jun 23 23:16:46 even ubuntu doesn't support 12.04 any more Jun 23 23:17:18 ubuntu supports 12.04 till next year Jun 23 23:17:34 got a better fix for gold linker maybe? Jun 23 23:18:06 if you can narrow it down may be Jun 23 23:18:20 I havent really looked at the problem you are trying to solve in details Jun 23 23:18:58 http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#detailed-supported-distros <= this is official or not official? Jun 23 23:19:14 it is Jun 23 23:19:31 well to say tested by yocto project Jun 23 23:19:43 and i sent you the error, in it's current recipe config it dosn't like gold/lto Jun 23 23:19:46 it doesnt say others are not supported Jun 23 23:19:57 disable lto then Jun 23 23:20:06 -fno-lto Jun 23 23:20:14 i use it as default Jun 23 23:20:56 afaict it's really ld.gold default it doesn't like Jun 23 23:54:33 guys, I want to point SRC_URI to local source Jun 23 23:54:47 as far as I remember I cannot use full path Jun 23 23:54:59 should I then set git mirror on my localhost? Jun 23 23:55:28 what's the best solution? My local source is git repo anyway Jun 24 00:13:34 Xz: you can use file:///x/y/x Jun 24 00:13:45 to access /x/y/z on your machine Jun 24 00:25:52 i am trying to remember how I disable sdl from qemu build. Any ideas? Jun 24 00:26:11 someone told me before and I didn't write it down. Jun 24 00:29:43 comment out PACKAGECONFIG_append_pn-qemu-native = " sdl" Jun 24 00:29:45 PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" Jun 24 00:29:49 in your local.conf Jun 24 01:35:29 Xz: use externalsrc.bbclass for that Jun 24 01:36:32 Xz: http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#building-software-from-an-external-source **** ENDING LOGGING AT Fri Jun 24 02:59:58 2016