**** BEGIN LOGGING AT Fri Apr 07 03:00:01 2017 Apr 07 07:27:19 bluelightning: could it be that bitbake-whatchanged is currently broken, with and without your bb-sigstuff branch? Apr 07 07:28:24 As a test, I did "bitbake m4 && bitbake-whatchanged m4" with poky master. Apr 07 07:28:48 I get lots of output about "Newly added tasks: (466 tasks)". Apr 07 07:29:56 When I do some actual change to m4 like commenting out "EXTRA_OECONF += "--without-libsigsegv-prefix"" in m4-1.4.18.inc, that change is not reported. Apr 07 07:34:01 Also, should "bitbake-diffsigs -t m4 do_build" work after "bitbake m4"? I just get "ERROR: No sigdata files found matching m4 do_build". Apr 07 07:34:37 Hmm, perhaps because it was taken from sstate? Apr 07 07:55:49 with the "bitbake -g" results change (a couple of months ago), how should I nowadays start the"why did this package end up on the image?" investigation Apr 07 09:43:47 Hi, I'm having trouble with Toaster, where I'm trying to build rpi-basic-image. after completing the parsing stage, the build seems to get stuck at the "Tasks starting..." stage and doesn't advance. I've tried completely deleting the poky folder cloned from github and starting from scratch but I always run into the same problem and can't advance further Apr 07 09:44:21 I'm using YP Core - Morty 2.2.1 Apr 07 10:47:41 Pharaoh_Atem: not started, maybe next week Apr 07 12:05:35 Pharaoh_Atem: btw why does dnf use python-iniparse (which is just as unmaintained as pygpgme)? are there plans to remove that dependency? Apr 07 12:11:23 jku: you can still use -g can't you? Apr 07 12:17:23 RP: yes but I probably don't know how to read the results... Apr 07 12:18:10 jku: try bitbake -u taskexp ? Apr 07 12:26:33 RP: what I mean is the "-g" output seems to be entirely related to tasks... That's reasonable but if I don't see how to figure out e.g. why is "openssl-conf" in an image (just as an example) Apr 07 12:44:26 Hi, little question here. I'm confused about a meta which named yocto bsp. I'm confused because of the combinaison of the term yocto and bsp in the same meta. For me, isn't yocto that should do the BSP for a board but the company or the guy who made the board. So what's does really is meta-yocto-bsp ? Apr 07 12:47:52 jku: specifically with package dependencies, the old -g code never really gave accurate information Apr 07 12:48:31 jku: I guess I was thinking about this from a "why did openssl get built?" which task information does hint at Apr 07 12:49:04 jku: I'd either grep the Packages files in tmp/deploy/ipk/*/Packages (or deb) or rburton does have a GUI for this as a WIP Apr 07 12:49:19 jku: you could grep pkgdata actually assuming you've built it Apr 07 12:53:09 yeah grepping pkgdata would work Apr 07 12:55:52 I think rburton's pkgdataui doesn't (at least currently) work for this Apr 07 12:57:31 kergoth: regarding my yesterday's question, I found a way to do what I wanted without affecting other images Apr 07 12:57:45 so `bitbake some-image -c listtasks` lists do_install. But if I create a symlink within a corresponding do_install_append, the file won't end up in the image. I even added it to the package's FILES_... :-/ Apr 07 12:58:26 If David Vincent is here (or if someone else understands the openssl-conf issue on ML), I'm available if you'd like to explain it to me like I'm 6 Apr 07 12:59:06 kergoth: If you set IMAGE_FEATURES = "read-only-rootfs" then you can force build to remove any packages you want Apr 07 12:59:29 kergoth: eg like ROOTFS_RO_UNNEEDED += " kernel-${LINUX_VERSION} kernel-image-${LINUX_VERSION} kernel-image-uimage-${LINUX_VERSION}" Apr 07 13:00:19 kergoth: so in your image you have only the packages you want without rpedends restrictions Apr 07 13:01:31 kergoth: and then with a function at IMAGE_PREPROCESS_COMMAND you can do anything custom things you want. eg erase move or other, right before image creation Apr 07 13:02:36 I wrote those things here if other people find them interesting also Apr 07 13:47:08 huh, didn't know about ROOTFS_RO_UNNEDEDED. the preprocess command is always a useful mechanism, its true, as is ROOTFS_POSTPROCESS_COMMAND Apr 07 14:15:24 hi all, I have a proprietary bluetooth stack (which ends up with static libs) that I cross-compile (for ARM) using a yocto-generated SDK Apr 07 14:15:52 all I have to do is to source the SDK environment script and launch make Apr 07 14:16:38 now I'd like to write a recipe to include the bt stack into the final image Apr 07 14:18:33 Hey guys, I have a best practice question about how to set up yocto to build similar images for multiple devices and the use of images and or distros Apr 07 14:18:34 I thought that a custom do_compile with oe_runmake could do the trick, but I was wrong: all my attemps ends with various "gcc: error: unrecognized command line option: -'marm'" Apr 07 14:19:40 which means (if I understand correctly) that the native compiler is invoked instead of the target one, am I right? Apr 07 14:19:49 For example, we are building yocto on devices A, B. Where A and B are almost exactly the same save for some network configurations and other small changes. Currently we do this by having a different yocto image for each device. We also have some global variables in local.conf which do some small customisations within the recipies. However as the images are all pulling from the same local.conf we have to do some ugly hacks within the r Apr 07 14:32:12 kanavin: I don't think anyone has asked about it, but I think it is something we do need to address Apr 07 15:04:26 Pharaoh_Atem: can you add a ticket for it? Apr 07 15:06:26 max843: in my opinion, best is to have two build folders and avoid global changes through local.conf. You can include these configuration on your machine or distro confs for example Apr 07 15:07:41 seebs: happen to be around? I broke pseudo Apr 07 15:12:40 woo! Apr 07 15:12:54 on conference call right now so not good at words but i'll catch up on logs soon. Apr 07 15:13:05 seebs: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11309 Apr 07 15:13:06 Bug 11309: normal, Undecided, ---, mark.hatle, NEW , Pseudo locks up with high numbers of threads Apr 07 15:13:45 seebs: never had an EMFILE before :) Apr 07 15:14:57 oooooh Apr 07 15:15:10 EMFILE The per-process limit on the number of open file descriptors has been reached. Apr 07 15:15:20 boy, that's interesting. Apr 07 15:15:34 kanavin: are you unable to file a bug in rhbz? Apr 07 15:15:39 you might be able to just raise the limit. Apr 07 15:15:53 kanavin: it helps when other people mention these things :) Apr 07 15:17:57 seebs: Does the pseudo server clear its existing fds on startup? Apr 07 15:18:59 seebs: must do, these fds are all socket connections Apr 07 15:19:25 seebs: I suspect that in case of EMFILE, pseudo needs to service existing connections before trying to accept new ones Apr 07 15:22:14 That might help. I'm not sure how much; it could well be we're ending up with 1k open sockets, and need ulimit changed. Apr 07 15:23:39 seebs: there are indeed 1k open sockets to it Apr 07 15:23:58 seebs: I'm just trying to think how it could unwedge itself Apr 07 15:28:16 Hmm. Apr 07 15:28:31 Check for EMFILE, if it gets EMFILE, wait until at least one client closes before trying to open a thing. Apr 07 15:29:15 i probably can't do it today but I can probably do it soon, i think i have a plan. Apr 07 15:29:44 seebs: this isn't urgent, the patches triggering this are for the next release Apr 07 15:29:56 seebs: I did think you'd find this interesting though :) Apr 07 15:30:23 seebs: and we will need a plan for the next release to handle this somehow Apr 07 15:41:28 i would suggest as a starting point capping jobs based on ulimit's reported max open files. Apr 07 15:42:39 Hi. Is there any info around on moving a build over from smart to dnf? It seems non-trivial. Apr 07 15:43:04 it's a total system upgrade.. the backend RPM(4) database and RPM(5) are not compatible.. Apr 07 15:43:13 DNF and smartpm were not compatible either... Apr 07 15:43:24 the package feed though would be, but needs to be regenerated with the DNF version of createrepo Apr 07 15:43:58 Yeah, that's ok. I've rebuilt everything, but the baseurls (among maybe other things) are not configured right for dnf to sync. Apr 07 15:46:24 seebs: right. I did just look at the code and it should serve existing clients before accepting new ones already :/ Apr 07 15:47:12 huh, just tried memres + bitbake-layers add-layer: xmlrpc.client.Fault: :not well-formed (invalid token): line 377, column 17"> Apr 07 15:47:29 is there any way to get an idea of the user's current open file count, to help slow down (or stop) new job creation until the count sufficiently drops? Apr 07 15:47:31 weird Apr 07 15:47:33 * kergoth wipes his build dirs Apr 07 15:48:18 I was wondering if there are changes needed in the recipes (or the local conf) or whether the existing PACKAGE_FEED_URIS, PACKAGE_FEED_BASE_PATHS and PACKAGE_FEED_ARCHS still works. Apr 07 15:48:36 I guess at least we change "all" to "noarch" ? Apr 07 15:51:04 It may actually "work" in that, if you wait long enough, it might actually finish things, it's just being inefficient because it's spending a ton of time calling accept when accept can't succeed. Apr 07 15:51:16 Hmm. That's a point; it should be clearing clients up eventually. Apr 07 15:51:30 Unless there's pipelines with multiple processes that all need to talk to the pseudo daemon. Apr 07 15:51:58 In which case we have a much more serious problem, because they *can't* be completed until other clients are accepted. Apr 07 15:52:14 seebs: I can't see it doing any work, it could be we're calling in with some long pipelines :/ Apr 07 15:52:33 Like, imagine a pipeline (a | b), where both a and b are doing (stat foo; sleep 5; stat foo) or something. Apr 07 15:52:37 And then run 1024 of them. Apr 07 15:52:49 There's no way to resolve that without being able to take more clients. Apr 07 15:52:57 seebs: right :( Apr 07 15:53:14 I can at least improve the performance, but I think that in all probability, the answer at that point is going to be "don't run that many things simultaneously, or increase ulimit". Apr 07 15:53:39 seebs, anyway to catch that behavior (ulimit problems or low open file counts) and report back on it? Apr 07 15:53:46 (I'm guessing the answer is no, not until it fails) Apr 07 15:54:19 seebs: I think we may need pseudo just to error/exit if it hits this as the current hang is a nightmare to debug :( Apr 07 15:54:24 seebs: or at least log something Apr 07 15:54:49 RP: I have the following scenario: two bbapends pointing to the same recipe, each in a separate layer, both setting FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:". The results is that the layer with high priority overrides what the low priority bbappend set, meaning that only the pathname from the high priority layer remains Apr 07 15:55:42 We could at least log the thing. Apr 07 15:56:01 Huh. Apr 07 15:56:25 So it occurs to me, we might be able to actually work around it, sort of. Apr 07 15:56:25 lsandov: do both directories contain the same file? Both prepends should end up applied Apr 07 15:56:26 RP: we have an scenario where yocto-bsp and devtool are being used to modify the linux-yocto recipe, so the layer create by the bsp tool sets some kernel configs which are not seen at the configure step, due to the problem I just mentioned Apr 07 15:56:38 The allarch ca-certificates:do_build has different signatures depending on the MACHINE. Apr 07 15:56:42 lsandov: same filenames? Apr 07 15:56:44 Because what if the server just forcibly disconnected clients with no pending requests? I believe the clients would restart. Apr 07 15:57:05 seebs: ah, that could work Apr 07 15:57:07 Meaning that they'd be able to resume sending things, but in the mean time other things could get processed. Apr 07 15:57:11 It would be sort of insane, but. Apr 07 15:57:21 seebs: it would beat hanging Apr 07 15:57:32 seebs, that sounds like a reasonable behavior.. if the client isn't doing anything.. close the connection until you have the ability to talk to them again.. Apr 07 15:57:48 it does mean the client side needs to know what to do when IT can't connect (via too many files problem) Apr 07 15:58:10 fray: the normal reconnect logic would just kick in wouldn't it? Apr 07 15:58:17 RP yes Apr 07 15:58:28 pohly: that sounds suboptimal, any idea why? Apr 07 15:58:47 lsandov: so the problem is probably more the overlapping filename that the prepends or the layers Apr 07 15:58:51 the normal reconnect logic though I think tries to spawn a new server (which will fail, because the server is already running).. but that would have to be verified Apr 07 15:59:13 fray: it would try to spawn, fail but they connect to the existing server? Apr 07 15:59:20 then Apr 07 15:59:27 -if- I remember correct, that is the normal reconnect logic.. Apr 07 15:59:46 very wasteful to spawn (as it will take yet another file descriptor to do), notice it's already runnign shutdown and then the client will connect to the existing server Apr 07 16:00:31 so something that will need to be looked at changing the behavior slightly may be reasonable in this situation. The connection close case should be fairly easy to look at, and an adjustment to the restart logic possible Apr 07 16:00:32 RP: comparison for MACHINE=intel-core2-32 and MACHINE=intel-corei7-64: https://pastebin.com/qqZzMqQt Apr 07 16:01:22 RP: basically it is because of a dependency on gcc/gcc-runtime_6.3.bb.do_fetch which itself depends on tune flags. Apr 07 16:02:04 RP: if you haven't guessed yet, that's what I found after extending yocto-compat-layer.py such that it actually changes the MACHINE during testing ;-} Apr 07 16:02:08 pohly: why would an allarch package depend on gcc-runtime? Apr 07 16:02:16 No idea Apr 07 16:02:52 that seems kind of odd Apr 07 16:02:54 pohly: there is certainly a bug somewhere in there Apr 07 16:03:38 don't suppose anyone wants to admit to understanding boost's configuration? Apr 07 16:04:25 pohly: just confirmed those dependencies are in my build too :/ Apr 07 16:07:29 The client shouldn't try to spawn a new server if it finds an existing server. And every connection will succeed at least once. Apr 07 16:08:08 If I maintain a client-order list, I can always bump the oldest client with no outstanding messages first. Apr 07 16:08:38 lsandov: Thanks - so you'd setup a new distro for each (the machines are both the same so machine makes less sense) and then add the configurations in the distro conf. I then, potentially, wouldn't need to have 2 different images - as I could set everything up in the distro conf. Can you foresee any problems with that? Apr 07 16:08:54 seebs, ok then my retry memory was wrong.. fair enough Apr 07 16:10:42 i don't understand boost, but I know that some things are tagged as depending on gcc-runtime.fetch or something similar as a way to say "this needs there to be a sysroot at all". Apr 07 16:10:56 max843: so two different distros and just one image target. sounds good to me Apr 07 16:11:23 x86-64-x86-64 gdb-cross-x86_64 do_build also has a problem for intel-corei7-64 and qemux86-64: do_configure has varying dependencies on tune flags. Apr 07 16:26:38 seebs: I'm wondering how you disable static libraries in boost. I think the answer may be "you don't" :/ Apr 07 16:35:47 pohly: there may be a patch on the list for that Apr 07 16:55:13 RP: found a pretty cool python package with a few memory profiling tools that might be of interest next time you're looking into that sort of thing: http://pythonhosted.org/Pympler/#usage-examples — 1. recursive object size calculation even for user classes, 2. identification of objects leaked out of scope between two points, and 3. tracking object and class lifetime and memory footprint Apr 07 16:55:37 sadly python memory analysis tools are few and far between, and heapy and meliae seem to be unmaintained, but this seems promising Apr 07 16:55:55 along with valgrind's massif or python memory_profiler to monitor overall usage over time Apr 07 16:56:29 memory_profiler seems to be just based on the rss of the process and its children, though, so can be more misleading Apr 07 16:57:55 RP: i'm guessing pympler probably can only track objects created by a class, not classes created by a metaclass, so not sure it could monitor the lifetime of our datastore, but still interesting Apr 07 17:00:46 kergoth: certainly sounds it, I'll make a note, thanks Apr 07 17:01:12 figured it was worth bookmarking for later reference :) np Apr 07 17:01:37 kergoth: I've love more time to go and look at that stuff instead of these bugs... :) Apr 07 17:02:12 customer issue, i don't have much choice in the matter right now :) Apr 07 17:02:50 kergoth: one of those days where you poke something, then realise the horror of what is happening, then discover that leads to another horror story and so on :/ Apr 07 17:03:01 ugh, been there, not fun Apr 07 17:07:05 Hey guys. I'm a little new to Yocto and I'm not understanding where I'm going wrong. I want to include the imx-test recipe from meta-fsl-arm in my build.... but I'm not sure how. Apr 07 17:07:16 Do I just add it to bblayers? Apr 07 17:09:44 The parent directory [../sources/meta-fsl-arm] was included in my last build's bblayers, but those tools aren't part of the system, so clearly I missed something. Apr 07 17:12:42 ValueError: invalid literal for int() with base 10: "or: Unable to find tunctl binary in Apr 07 17:12:42 '/data/kergoth/mel/elm/test/build.pkgconf/tmp/work/i586-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin', please bitbake qemu-helper-native" Apr 07 17:12:58 so much for runqemu.. Apr 07 17:14:24 kergoth: there are various patches around which seem to fix some usecases and break others Apr 07 17:28:34 I guess I was looking for CORE_IMAGE_INSTALL += "imx-test"? Hope so. Apr 07 17:29:00 bitbake didn't complain... I'll find out in 6 hours when it's done building. Apr 07 17:30:51 majuk: i assume you mean CORE_IMAGE_EXTRA_INSTALL? Apr 07 17:47:48 kergoth: Yes, yes I did Apr 07 17:50:07 okay, good, just checking :) Apr 07 18:04:45 kergoth: lol, I would think bitbake would throw a fit if I put something else in there. Apr 07 18:05:15 not sure what you mean by that Apr 07 18:05:19 you can set any variable you want Apr 07 18:05:29 a typo in a variable name will just be setting a new varaible that isnt' used anywhere, which is harmless Apr 07 18:05:47 True, didn't think like that Apr 07 18:06:07 FINE. Just BE RIGHT. Apr 07 18:06:10 :P Apr 07 18:08:04 :) Apr 07 18:10:35 Since you're getting your right everywhere, how about you drag the chromium-imx patch onto chromium 54.x Apr 07 18:10:57 So I don't have to try and fail repeatedly to. Apr 07 18:11:03 You'll just do it right the first time. Apr 07 19:56:21 Hey, I'm having an issue where I'm trying to have grub behind two different yocto partitions. When I select a partition though, it seems to be random which one actually boots. Do you think this is an issue with the syslinux config? Apr 07 20:41:32 for some reason, bitbake is not complaining if a recipe has no LIC_FILES_CHKSUM Apr 07 20:46:12 Do you have LICENSE set to CLOSED? Apr 07 20:48:09 neverpanic: no, that is the problem Apr 07 20:48:38 neverpanic: just remove the proper line of a recipe, try bitbake -e and worked Apr 07 20:51:43 I think the check is in do_configure(), so you may want to check whether the recipe does do_configure[noexec] = "1" Apr 07 20:52:06 That may have been fixed meanwhile, but it was a problem back when I looked at it last time Apr 07 21:11:51 neverpanic: I see Apr 07 21:12:05 neverpanic: I will file a bug Apr 07 21:14:02 neverpanic: the recipes I was looking for has no do_configure[*] = 1 Apr 07 21:14:20 neverpanic: but good point, that may the reason for some Apr 07 21:14:27 some/some recipes Apr 07 21:24:36 Yeaaaaa, the image is marginally bigger. Think I got my imx tools this time. Apr 07 21:24:47 I'm basically a wizard, Harry. Apr 07 21:26:35 Yea I do. YEA I DO. Al-a-ka-ZAM. Apr 08 00:10:55 hi, I'm trying to (overload / override ?) a wpa_supplicant.conf file with another in my own layer. I was able to make this work with the /etc/network/interfaces file, but no permutation I've tried works for this. Apr 08 00:11:29 I followed https://communities.intel.com/thread/49251, and https://communities.intel.com/thread/63267 as references Apr 08 00:12:24 every attempt I've made, ends up with no wpa_spplicant.conf in the fs Apr 08 00:12:50 anything I'm missing? Apr 08 01:20:38 mhilt: take a look at https://github.com/kraj/meta-himvis/commit/0bb40412d1ed608fcef10b6f183d3c76160316d4 Apr 08 01:21:03 mhilt: ofcourse you need to replace the wpa_supplicant.conf-sane with your own but you get the idea Apr 08 01:25:12 thanks khem -- that's actually exactly what my first attempt looked like ... Apr 08 01:26:48 apparently though, it seems it is packaging the change correct ... since it is appearing in the package directory correctly deploy/rpm/.. Apr 08 01:27:10 but then not in my image Apr 08 01:38:48 its strange unless you tell me that you have a post processing function which mucks with image Apr 08 01:49:34 well, I am still very much learning Yocto / OE - but I don't think there's any post processing. I have made a custom layer of course, but also define my own distro within it Apr 08 01:50:07 there is another layer provided by the dev board supplier, but I don't think it's doing any post processing on the image **** ENDING LOGGING AT Sat Apr 08 03:00:02 2017