**** BEGIN LOGGING AT Wed Oct 15 03:00:00 2014 Oct 15 05:32:48 Hi Oct 15 05:33:54 Hi all Oct 15 05:45:48 I am getting some missing symbol error with GCC-4.4.2 which I have compiled using openembedded bitbake Oct 15 05:46:16 Please refer to http://pastebin.com/iBV29p1h link for more details Oct 15 08:16:47 Hello all, Im getting the following issue when adding qt5 toolchain package group to my own image packagegroup: * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-qemu-image: * qtwebkit-mkspecs * qtwebkit-qmlplugins * qtwebkit (= 5.3.2-r0) * Oct 15 08:16:47 does anyone faced the same issue ? Oct 15 08:23:16 morning all Oct 15 08:23:59 kbouhara: I haven't but it would be worth double-checking the README file for meta-qt5 to ensure you haven't missed any configuration Oct 15 09:24:16 bluelightning: ok I'll do that thanks Oct 15 09:32:46 hi, I have never understood this dependency: gdbserver: unsatisfied recommendation for glibc-thread-db Oct 15 09:32:50 it looks broken to me Oct 15 09:33:17 ERROR: Nothing PROVIDES 'glibc-thread-db' Oct 15 09:33:27 it is probably some eglibc package instead, but I assume this ought to be fixed. Oct 15 09:35:23 hello Oct 15 09:35:38 is there a way to display my DISTRO_FEATURES var ? Oct 15 09:36:01 sce: bitbake -e foo | grep ^DISTRO_FEATURES? Oct 15 09:48:50 lpapp: meta/recipes-core/eglibc/eglibc-package.inc:RPROVIDES_eglibc-thread-db = "glibc-thread-db" Oct 15 09:49:39 bluelightning: yeah, I think that should be removed, IMHO. Oct 15 09:49:48 why? Oct 15 09:49:55 see above, it is source of confusion. Oct 15 09:50:07 I have been looking for the package everywhere for about half an hour. Oct 15 09:50:11 and could not find anywhere. Oct 15 09:50:14 the source *is* eglibc Oct 15 09:50:20 that line is from the eglibc recipe Oct 15 09:50:21 no Oct 15 09:50:23 yes Oct 15 09:50:31 oh, well, I will not argue. Oct 15 09:50:51 if you think I have had fun-time looking for the package, there is nothing to discuss. Oct 15 09:51:35 will just fix it in our fork. Oct 15 09:54:16 that package exists here, going right back to dylan Oct 15 09:55:05 it gets renamed to libthread-db1 per debian library package renaming, but that's all handled internally Oct 15 09:55:12 let us just drop the topic, you do not see my pain, and I feel it insane. We will not reach any agreement with two completely conflicting opinion. Oct 15 09:55:35 I don't know why that library package would not exist on your system Oct 15 09:55:49 bottom line is gdb expects that library to exist, removing the dependency would be the wrong thing to do Oct 15 09:57:54 it has nooooothing to do with removing a dependency. Oct 15 09:58:11 when opkg tells me a package is missing, I *expect* bitbake to build the package for me if I say bitbake package. Oct 15 09:58:17 it *should* figure out the details. Oct 15 09:58:30 that is one serious flaw in my opinion Oct 15 09:58:50 secondly, when I say bitbake eglibc (or whatever), it does not yield any such packages, either. That is the second big problem. Oct 15 09:59:17 at least these are problems for me anyhow; ymmv. Oct 15 09:59:54 I have been trying to solve such a simple issue for about 40 minutes now. Still could not understand what is going on. Oct 15 10:00:24 and *anyway*, when I say bitbake gdbserver, it should provide all the dependencies automatically, that is the third big problem of mine. Oct 15 10:00:44 and normally, it does Oct 15 10:01:05 do you have an eglibc-thread-db directory under the packages-split directory for eglibc? Oct 15 10:04:27 the fourth big problem of mine is that I do not know why it is not optional. Oct 15 10:04:34 I am not using any threading after all. Oct 15 10:05:01 or is it necessary for gdbserver to keep working because it is written with threads? Oct 15 10:05:57 re 3: find ./tmp/deploy/ipk/ -name \*glibc-thread-db\* yields nothing, but I have nativesdk-eglibc/2.17-r3/packages-split/nativesdk-eglibc-thread-db Oct 15 10:07:18 lpapp: as I said above, the package is renamed to libthread-db1 as per debian library package renaming Oct 15 10:07:39 do you have an eglibc-thread-db directory under the packages-split directory for eglibc? Oct 15 10:09:18 why is it renamed and _not_ required that way with opkg? Oct 15 10:09:33 this is what I was trying to write... Oct 15 10:10:04 that is bad bad bad bad bad Oct 15 10:10:24 opkg should know that libthread_db1 provides that Oct 15 10:10:44 but _the user_ will not know. Oct 15 10:10:51 that is the whole point I am trying to make. Oct 15 10:10:52 the user shouldn't have to care Oct 15 10:11:06 yeah, right ... Oct 15 10:11:11 he should care about wasting an hour :) Oct 15 10:11:17 to install gdbserver on the board lol Oct 15 10:11:29 if you answer my question we can start to debug it, otherwise there's not a lot I can do Oct 15 10:12:00 I think I already did, and I also do not see what to debug here. Oct 15 10:12:11 it is fundamentally flawed IMHO, and should be revamped. Oct 15 10:12:21 if X is the dependency, opkg should say X, no matter what. Oct 15 10:12:50 you can think of it the other way around, too, if opkg says X, no matter what, Yocto should generate that. Oct 15 10:13:03 like I said, normally it does Oct 15 10:13:31 no no no, you said there is no eglibc-thread-db package. Oct 15 10:13:37 you can also disable debian.bbclass if you want Oct 15 10:13:37 let me put it clear: Oct 15 10:13:58 [1] opkg says eglibc-thread-db -> find ./tmp/deploy/ipkg -name \*eglibc-thread-db\* should find it Oct 15 10:14:01 OR Oct 15 10:14:23 [2] opkg says libthread-db1 Oct 15 10:14:34 everything else is "fun-time" for the end user. Oct 15 10:14:41 grep packages files so that you cover also all RPROVIDES Oct 15 10:14:50 using find to do that is stupid Oct 15 10:15:05 and not surprising that it doesn't cover all cases Oct 15 10:15:10 doing simple things to achieve the goal is not stupid IMHO Oct 15 10:15:19 and _anyway_, grep will not help, see above: meta/recipes-core/eglibc/eglibc-package.inc:RPROVIDES_eglibc-thread-db = "glibc-thread-db" Oct 15 10:15:25 the point is either the package is there or it isn't, so far we haven't even been able to determine that Oct 15 10:16:14 lpapp: "simple things" which searches for something else than what you need and what opkg sees _is_ stupid Oct 15 10:16:54 that _is_ stupid yes, but that means _opkg_ and/or _Yocto_ is stupid, too, in this sense. Oct 15 10:17:05 it should make life hard, not difficult Oct 15 10:17:09 who cares about some debian thing. Oct 15 10:17:11 packages-split as suggested by Paul or greping Packages files is what you need and what opkg will use to determine if the runtime provider is there or not Oct 15 10:17:28 it just confuses the user. I will certainly patch that out in our fork since IMHO, makes.sense.no.dat. Oct 15 10:18:23 I understand that is what is needed, but what I am trying to write is, that is _not_ what should be needed. Oct 15 10:18:23 hey guys Oct 15 10:18:33 any idea who should provide system-auth? Oct 15 10:18:36 the pam config file? Oct 15 10:18:44 no need to patch it out, just disable debian.bbclass... and if you don't like the dependency at all, use a bbappend to clear it, problem solved Oct 15 10:18:57 the whole system should not be this complex, since it is really superfluously unnecessary IMHO, with all due respect whoever wrote this "feature". Oct 15 10:19:32 in fact, I am not even using a debian system, hack. Oct 15 10:19:44 nor on the host, nor on the target, why on earth would it be automagically done like that by default?/ Oct 15 10:20:08 I see zero gain, and it wasted one hour of my time as well as some of yours all ... Oct 15 10:20:12 because it's very useful for majority of distributions Oct 15 10:20:39 right, we will need to agree to disagree, but I guess that is what forks are good for :) Oct 15 10:21:47 OE allows you to configure and customize what you want, you don't need to call it "fork" every body has own configuration and that's how it's supposed to be used Oct 15 10:22:55 no, I do not want this debian class mess in my tree at all Oct 15 10:23:02 I *do not* want it to be configurable. Oct 15 10:23:36 I want it to be killed with fire in our tree, so that no one can waste the valuable developer time with it. Oct 15 10:24:00 heh, I'm off - going to watch trees grow.. Oct 15 10:25:30 and even if this debian mess is silently and automagically screwed up under the new user, the opkg generation *should* be modified so that opkg does report the renamed stuff. Oct 15 10:26:25 I have never seen any distribution yet that reports dependency foo, but then you cannot find such a package, and rightfully so IMHO. Oct 15 10:26:44 so I am not sure what majority was referred above. Oct 15 10:27:05 even in debian, if I get a missing dependency, I can find that package for installation. Oct 15 10:27:20 IMHO, it is some broken debian class or something :) Oct 15 10:28:26 an end user of the system is _not_ supposed to dig into oe/yocto/poky/whatever sources to install a dependency on the distribution. That is not acceptable. It is the system developer that understand the buildsystem, but the end user should _not_. Oct 15 10:28:33 it is just again, anti-KISS design IMHO. Oct 15 10:28:46 understands* Oct 15 10:29:50 if any, I would personally make the default in our fork "no no debian" and give a big warning if someone enables it, but I do not see the need for enabling it altogether, personally. Oct 15 10:31:55 Hi! I need to add support of radeon driver (xf86-video-ati) in my target machine. Any idea how to add Oct 15 10:31:56 ? Oct 15 10:32:31 I do not even mention the missing documentation for disabling a class, because that is just 100th rank issue, although it goes undocumented or at least it is very hard to discover. I have been trying to grep for it in the documentation, but nothing gives me an example, really. Oct 15 10:33:19 S_A: get that from the bloated meta-oe layer Oct 15 10:33:30 S_A: the layer indexer is your friend, http://layers.openembedded.org/layerindex/branch/master/recipes/?q=xf86-video-ati Oct 15 10:35:32 lpapp: git grep INHERIT.*debian will tell you that debian.bbclass is enabled through INHERIT_DISTRO, then just set that var to a value that does not include "debian" Oct 15 10:36:06 no, it will not. Oct 15 10:36:10 lpapp: as with the other changes, you do not need to fork in order to change it Oct 15 10:36:26 I am using my own tree, I do not have the poky history. Again, I am not a poky developer, I am a poky _end user_. Oct 15 10:36:36 I think there is some confusion what end user means. Oct 15 10:36:48 well, you can of course do as you please, I gave you the answer in any case Oct 15 10:37:00 bluelightning: huh? I do not need to fork it to kill it with fire? Oct 15 10:37:33 I want *my tree* to not even considerate it by default, and going even more: I do not want anyone to enable it ever. Oct 15 10:37:36 you do not need to fork poky in order to change things like this, you can just set variables in your distro config Oct 15 10:37:43 I do not see how that can ever happen without fork. Oct 15 10:37:45 we do this so that you have less pain when it comes to upgrade Oct 15 10:38:17 quilt has existed for decades, much less painful than finding a single dependency. Oct 15 10:38:47 I'm not sure how that relates to this... Oct 15 10:38:53 nvm Oct 15 10:42:02 like I said an hour ago, we will not reach any common agreement here. We have different definitions of what end user is. Oct 15 10:42:14 from the ground up, essentially. Oct 15 10:43:43 our system allows for different distro policies to exist, it even makes it relatively easy for those to be applied on top of the core metadata without changing that core, saving time when that core is upgraded Oct 15 10:44:35 the acknowledgement that people want to be able to do different things with the system is built-in Oct 15 10:44:42 yeah, I, as a distribution developer, fantastically wasted one hour after our user also wasted a significant amount of time. Oct 15 10:45:07 you think this is wonderful, I think it is awkward, let it be so. We will not convince each other. Oct 15 10:45:19 I do not claim it is perfect, I never would Oct 15 10:46:35 but I am used to not getting my pain heard here anyway :( Oct 15 10:47:04 to be frank a lot of that is about how you ask for things sometimes Oct 15 10:47:24 or how you respond when an attempt is made to help work through what the problem is Oct 15 10:48:05 true, I'm still partially interested to see if the package was really created or missing Oct 15 10:48:27 but instead of simple answer, there is useless discussion about configuration/killing-with-fire Oct 15 10:48:38 useless for you, and marginal for me. Oct 15 10:48:52 whether it was created was completely irrelevant, but no, it was not created as I said at least twice. Oct 15 10:49:05 no you didn't Oct 15 10:49:05 I am sorry if you had missed it twice. Oct 15 10:49:14 I gave up on writing it the third time if people do not read what I write. Oct 15 10:49:21 anyway, I am off /me fixing this in the fork Oct 15 10:49:29 all you said is that there isn't a file with that filename Oct 15 10:49:40 which isn't the same thing as "runtime provider" Oct 15 10:50:17 in our project, there will be no such stupid time wasters. Oct 15 10:50:33 that is, what opkg will report will be the dependency, no hidden magic to confuse the user Oct 15 10:50:45 Yocto does not give this option to us by default, so we have to tweak, no not configure, at all. Oct 15 10:51:02 configure means I already wasted one hour (effectively more) and our end user, too. Oct 15 10:51:08 it is too late to realize this is configure. Oct 15 10:51:14 the time is already wasted; this is not acceptable. Oct 15 10:51:54 so again you're moving the discussion somewhere else and we'll never know if there is something wrong with gdbserver or not Oct 15 10:53:10 JaMa: http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem Oct 15 10:53:23 I guess not, but I don't want to waste more of my time _trying_ to help you stop wasting your time Oct 15 10:53:35 thanks. Oct 15 10:54:27 11:34:37 < lpapp> hi, I have never understood this dependency: gdbserver: unsatisfied recommendation for glibc-thread-db Oct 15 10:54:30 11:34:41 < lpapp> it looks broken to me Oct 15 10:55:37 JaMa: I do not think you understand my issue, let it be so. Oct 15 10:55:50 you think the real issue is whether libfoo-db blabla is generated. Oct 15 10:55:56 whereas that is red herring in my opinion. Oct 15 10:56:29 (that is why I linked the XY problem thread above because I think that demonstrates the situation here) Oct 15 10:56:33 let me explain how this could have gone Oct 15 10:57:08 hypothetically Oct 15 10:58:00 is the package produced? no it's empty and thus never exists, why? let's look at the configure output... right, we're configuring out threading, therefore that package shouldn't be expected to exist Oct 15 10:58:23 then we could look at trying to pick that up and not having the dependency under those circumstances Oct 15 10:58:55 now, I've no idea if that's what's happening, because we weren't able to follow any kind of debugging path even though doing that might seem pointless to you Oct 15 10:59:35 it's only in digging to find the root cause (as pointed out in the link you yourself posted above) that we can get to that point Oct 15 11:00:57 I wrote it several times what my root cause is. Do I really need to write it again? I can, but I do not feel appreciated by not being heard. Oct 15 11:01:44 "That is, you are trying to solve problem X, and you think solution Y would work, but instead of asking about X when you run into trouble, you ask about Y." -> My problem is X, you are asking about Y. Oct 15 11:01:50 if you did then somehow I missed it; and saying "I already said it I won't say it again" probably takes more effort than just repeating it Oct 15 11:01:58 my problem is: why on earth do I have to install a different package than mentioned?? Oct 15 11:02:04 maybe what you said and what I was asking about were two different things Oct 15 11:02:09 your question is: do you have the renamed package generated?? Oct 15 11:02:57 yes, I was attempting to figure out why you even got the failure Oct 15 11:03:34 so, you confirm you were asking about Y, and I was interested in X, great. Now, let us not go through that again. Oct 15 11:03:45 why is there no package named eglibc-thread-db or even glibc-thread-db ? because of debian renaming; and we talked about how to turn that off, which is an option that is already available Oct 15 11:04:03 yes, I realized it *after* wasting my and my user's time. Oct 15 11:04:11 wonderful, but not that stuff again ever. Oct 15 11:04:30 just .... not! Oct 15 11:04:46 not not not, this is not acceptable, and I am very likely not alone. Oct 15 11:04:57 whether the libfoo-db stuff is generated is Y answer. Oct 15 11:05:18 I do not care whether it is generated or not. I want opkg to report the right stuff for me * all the time * _and_ * by default *. Oct 15 11:05:42 that means, it is not configuration, it is default, when I clone Yocto. Oct 15 11:05:57 opkg can only report what it knows, and all it knows is that a dependency exists on glibc-thread-db and nothing in all of the packages produced provides that Oct 15 11:06:21 I do not care. It is unacceptable, the system needs improvement. This is not a configuration thing. Oct 15 11:06:35 anyone cloning Yocto will get into this trouble without superknowledge upfront. Oct 15 11:06:47 Sorry, but this is not acceptable in _my_ projects with due respect whatever others do. Oct 15 11:07:17 I think that might be an exaggeration, because just cloning and building the system to start with I don't think you could hit this error Oct 15 11:07:44 you have spent time making quite considerable modifications to your system including changes to poky itself, in your fork Oct 15 11:08:23 of course, none of the patches was accepted in upstream ever :) Oct 15 11:08:32 that is provably false Oct 15 11:08:35 were* Oct 15 11:08:54 some of your patches were not accepted, sure Oct 15 11:08:56 I am probably blacklisted from contribution. Oct 15 11:09:18 but I do not care. I think I got all the information that I needed to proceed with my ideas, thanks. Oct 15 11:09:19 not at all, we accept reasonable changes from all community members Oct 15 12:08:43 has anyone built image for raspberry b+ with oe? Oct 15 12:10:07 ritou: yes Oct 15 12:11:54 lpapp: is there any info about that somewhere? id like to crossbuild stuff for the b+ i found older posts but not sure this would work with b+ : http://www.cnx-software.com/2013/07/05/12mb-minimal-image-for-raspberry-pi-using-the-yocto-project/ Oct 15 12:12:46 Hi Oct 15 12:13:21 http://www.pimpmypi.com/blog/blogPost.php?blogPostID=7 Oct 15 12:13:28 Can anyone guide me to integrate Xorg graphic driver Oct 15 12:40:20 hello, does someone know why largefile in DISTRO_FEATURES is an optional distro features Oct 15 12:40:30 hello, does someone know why largefile in DISTRO_FEATURES is an optional distro feature Oct 15 12:42:51 sce: it's been that way for a long time; perhaps on older 32-bit systems there were memory constraint issues with having it enabled and it wasn't really needed? not sure Oct 15 12:43:09 okay so no know sideeffect ? Oct 15 12:43:34 of enabling it or removing it? Oct 15 12:43:39 it's on by default Oct 15 12:44:04 yes in poky.conf you mean ? Oct 15 12:44:23 i'm having a special conf that's why it was not on Oct 15 12:44:38 but i wanted to confirm that there is no sideeffects Oct 15 12:44:53 poky.conf adds it but it's actually defaulted to on in OE-Core's defaultsetup.conf as well Oct 15 12:45:18 no, I wouldn't think there would be any sideeffects Oct 15 12:45:46 it's not necessarily complete for 32-bit systems, that's a separate issue though (there is a bug open to track that) Oct 15 12:46:46 ok thx for your enlightning ;) Oct 15 12:47:36 sce: because what is the point of enabling it if you do not need it? Oct 15 12:47:41 it would be illogical to do so. Oct 15 12:47:56 i need it that's the point Oct 15 12:47:56 see, in my case, I have a very small flash, so inherently, I cannot have large files. Oct 15 12:48:14 I answered this: "hello, does someone know why largefile in DISTRO_FEATURES is an optional distro feature" Oct 15 12:48:15 but i guess my team sets originally the DISTRO_FEATURES without largefile Oct 15 12:50:42 is there some documentation on how EXPORT_FUNCTIONS works? Oct 15 12:51:09 the ... what? Oct 15 12:52:19 anyway thx alll Oct 15 12:52:23 (I have one bbclass here which defines do_compile() and another class which sets foo_do_compile() and uses EXPORT_FUNCTIONS - and I am not really sure if/how I can use both classes together) Oct 15 12:52:25 canci: http://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#flexible-inheritance-for-class-functions Oct 15 12:52:46 Hi Oct 15 12:52:51 lpapp: thank you Oct 15 12:54:11 Can anyone provide me information about how to integrate bx-org display driver in YOcto Oct 15 13:10:28 I am trying to use xorg graphics driver with the yocto project Oct 15 13:10:44 Can anyone plese help me out in integrating Oct 15 13:22:53 Adam_: which graphics driver? Oct 15 13:23:29 is there already a recipe that builds and/or packages it? Oct 15 13:25:40 I am having a recipe Oct 15 13:25:46 ati_raedon Oct 15 13:26:08 i have enabled the kernel mode settings Oct 15 13:30:45 ok, so it seems like you'd only need to add the package to your image then Oct 15 13:30:59 see here for several ways of doing that: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage Oct 15 13:32:03 ok Oct 15 13:35:06 Is there any way of compilig Xorg alone Oct 15 14:05:03 Adam_: I guess bitbake xserver-xorg Oct 15 15:08:53 is there a way to specify that a recipe cannot be built in parallel with any other package? I have a very strange failure case with boost, where it fails to build when building an image, but if built as a target (cleannstate of boost first), it succeeds. Happened multiple times now on two different boxes. Oct 15 15:08:57 I'm sure it's a FAQ but, is there any way to remove an item from DISTRO_FEATURES without having to make your own distro? (No matter how hacky) Oct 15 15:10:10 have you tried setting DISTRO_FEATURES = "FEATURES YOU NEED" in local.conf? Oct 15 15:11:09 blloyd: ah yes, doing that now, but i'd like a solution that works automatically for multiple developers Oct 15 15:11:45 add that line to a layer.conf file? Oct 15 15:13:28 blloyd: ah those are parsed at the right time. thanks, i'll give that a go. Oct 15 15:14:03 note that if you just want to remove features, you can do DISTRO_FEATURES_remove = "foo" Oct 15 15:14:39 ndec: it looks like that one is not in dora Oct 15 15:14:46 ndec: cool. When did _remove get added. And is it documented? Oct 15 15:15:09 because I haven't seen it in master docs either... Oct 15 15:15:26 blloyd: how does boost fail? Oct 15 15:16:09 i think it was added in dora. Oct 15 15:16:24 with regard to advertising DISTRO_FEATURES_remove, I'm wary of anything that discourages people from creating their own distro config Oct 15 15:16:42 if anything we should be making that part easier rather than making it easy to avoid Oct 15 15:18:15 filling up local.conf with things that belong in the distro config if left unchecked can lead to problems reproducing the same build later on another machine Oct 15 15:18:44 I'm not entirely sure what fails it first time. However, once failed I've looked and cc1plus segfaults on almost instantly on subsequent attempts to build. I suspect it's a resource fauilure where an invalid .o or .a is left and later calls crash when using it. Oct 15 15:19:43 blloyd: hmm... boost is quite large, is it possible you're running out of memory and the OOM killer is getting involved? a quick look at the kernel log should reveal if that's the case Oct 15 15:20:58 I looked and didn't see it. That is exactly what I suspected. Why I asked about something to restrict it. Cut down on resources used at the time. But 16GB with 64GB virtual ram shouldn't run out of ram.... Oct 15 15:28:01 blloyd: right, scratch that then Oct 15 15:28:35 it sounds odd, what we'd really want is more information on that first failure Oct 15 15:29:01 to answer your question, there is no workaround other than setting dependencies such that one must occur before the other Oct 15 15:30:34 For full disclosure: I do have a .bbappend for boost to enable some of the libraries that were not enabled by the official package. I like how the latest package handles it's python now. Oct 15 15:31:30 ok, that might account for us not seeing the issue up to now, but it doesn't necessarily excuse us from fixing it ;) Oct 15 15:31:32 thanks blue. What I suspected, but was hopeful in case there was some new capability I hadn't noticed yet. Oct 15 15:32:31 I guess what I'd say is, if you manage to get more info on the initial failure please file a bug to track it and include the info on what extra libs you're enabling Oct 15 15:32:54 Yes, especialy since I plan to propose ALL boost libraries get built, and there is a library that shouldn't be built all the time do it just like the python library is done now. Oct 15 15:37:10 from a diagnosing the problem standpoint, is there a somewhat easy way to see after a build completes what tasks were running in parallel? For instance, if boost build tries to use a file that is being written by another parallel job causing the segfault, it would be helpful to know what other tasks were making sysroot mods at the time. Oct 15 15:37:34 so, kind of Oct 15 15:37:50 there is support for writing out a "bootchart" style chart which shows which tasks were executing when Oct 15 15:38:40 I wonder if that will always show enough of an overlap to be definitive though, but it may be worth looking at Oct 15 15:39:04 the odd thing is if it really is just do_rootfs, that shouldn't ever be making changes to the sysroot Oct 15 15:43:12 should and is are too different things, unfortunately. But I was mostly wondering about the possibility of a auto dependency discovery adding usage of a library the image has but which boost recipe doesn't consider a dependency. If the library isn't all the way there then it could account for a build failure that leaves bad .o files. Oct 15 15:51:15 right, yes that could happen Oct 15 15:51:46 we do have a script to check for that sort of thing but I believe it's more suited to testing in world build situations Oct 15 15:53:43 I'm not 100% familiar with boost itself but if it does checks within configure to see what dependencies are available and actually reports what is being enabled, you could build just boost from clean (or just from sstate), then build your image and then rebuild boost and see if the configure logs (or even the output with buildhistory) are different Oct 15 15:54:30 we have a built in sanity check now for runtime deps (e.g. auto-added shlib deps) which are missing build deps, afaik, if thats what you mean by usage of a library Oct 15 15:55:40 kergoth: right, in master, yes **** ENDING LOGGING AT Thu Oct 16 03:00:00 2014