**** BEGIN LOGGING AT Tue Sep 27 02:59:59 2016 Sep 27 03:12:17 mrkiko: pretty off-topic Sep 27 03:58:18 problem solved, thank you guys Sep 27 03:58:22 have a good day Sep 27 03:58:25 thanks Sep 27 03:58:27 sorry, exiting Sep 27 04:51:43 hi guys, I am trying to add a new task to the kernel tasks and I face a strange issue Sep 27 04:52:48 basically I am trying to add a task in between do_patch and do_configure Sep 27 04:58:11 here is actual error: http://pastebin.com/MNHE62Ks Sep 27 05:10:43 and here is the entire error I get: http://pastebin.com/vngJ1qNQ Sep 27 05:10:47 any clues? Sep 27 06:20:22 Hi @all ... I see some strange behaviour in a custom project ... I have a package providing the packages PN, PN-dbg, PN-dev and PN-staticdef so basically a binary and a helper lib I want to use statically. If I depend on this lib in another package and build the sdk the PN and PN-dbg package end up in the target sdk ... but I would expect/need to have the dev and staticdev package? Sep 27 08:07:29 GCCVERSION looks like a quite global setting, and KERNEL_CC does not look like it was designed for overriding - there is no support for building the kernel with a different compiler version than the rest ? Sep 27 10:39:41 I have a challenge I don't know which end to approach, so bear with me: We have a tools repo, which contains tools and helpers for configuration management. It is checked out in top level. Now I need to access a tool in this repos bin/ dir during builds of an image recipe. The question is how to access it Sep 27 10:40:39 a) Should I add it as a layer? Can I add this layer's bin/ to PATH in layer.conf? Sep 27 10:41:42 b) Should I make it as a native recipe in another layer and refer to this tools repo as SRC_URI? Sep 27 10:42:48 c) Access the tool directly, such as ${OEROOT}/../tools/bin/mytool, and thus make all kinds of horrible path assumptions? Sep 27 10:46:59 for (a) i suspect extending PATH will work Sep 27 10:47:12 so (a) or (b) should work Sep 27 10:49:13 Thanks. Do you have any examples of any native recipes off hand? E.g. in poky or meta-openembedded to look at? Sep 27 10:49:57 oe-core is full of native recipes Sep 27 10:50:25 (they're just recipes that either inherit native, or use bbclassextend=native to magically inherit native) Sep 27 12:31:50 is there an easy way to use OE-Core master/next with Yocto? Sep 27 12:35:24 git checkout origin/master? Sep 27 12:36:27 Hi. Did anybody ran a docker daemon on qemux86-64? Sep 27 12:43:16 What am I doing wrong here: https://bpaste.net/show/56abe29e1abc. It failing over not finding vsi in the install step Sep 27 12:48:47 use ${S}/vsi Sep 27 12:49:04 erm, ${WORKDIR}/vsi even Sep 27 12:49:24 as you're just putting stuff into WORKDIR (via the fetch) but install's cwd is $S, which is $WORKDIR/$PV-PN Sep 27 12:49:31 you should also be getting a warning that S doesn't exist Sep 27 12:49:44 rburton: yeah, I see a lot of recipes setting S="${WORKDIR}", but isn't S set to.... yeah, right, $PV is in the default. Thanks Sep 27 12:49:57 set S=${WORKDIR} and it will work, and do the right thing Sep 27 12:50:23 don't set PROVIDES, call the recipe vsi-native.bb Sep 27 12:51:04 also native.bbclass sets PACKAGES='' for you Sep 27 12:52:46 Thanks! (the price to pay to copy and paste other's work) Sep 27 12:53:00 rdepends can be removed too Sep 27 12:54:33 what about using FILESEXTRAPATHS_prepend vs setting FILESPATH directly? Sep 27 12:56:00 is that a convoluted way of getting to the files that are in your layer's top-level bin directory? Sep 27 12:56:20 yes Sep 27 12:56:26 if so, why not move them into the recipe's directory if you're going to be installing them in a recipe Sep 27 12:56:31 and apparently the wrong way according to your description :P Sep 27 12:57:49 Because it's shared code, used by other non-yocto builds Sep 27 12:58:05 either works then i guess Sep 27 12:59:15 But after a discussion at the office, we don't want to add a separate meta layer for the yocto native things. So we ended up making the tools repo into a layer, adding a recipes/ directory for the yocto specific bits Sep 27 13:05:20 Is there an easy way to find what (native) package a future package belongs to? E.g. I'm looking for the required dependencies for python modules, and want to make sure my RDEPENDS is set right Sep 27 13:06:37 native stuff doesn't get packaged, its all or nothing Sep 27 13:07:10 well, a subset of all. no target binaries, for example. Sep 27 13:07:18 rburton: yeah, ok, packages as in, which RDEPENDS is needed for xyz feature Sep 27 13:07:36 is there a trick for grepping or finding? Sep 27 13:08:07 not sure what you're asking Sep 27 13:08:12 I sorely miss ubunuts packages.ubuntu.com that can find specific files, but I do understand that yocto doesnt work like that Sep 27 13:08:20 oe-pkgdata-utils can and does Sep 27 13:08:31 (for target, as its *pkgdata* not sysrootdata) Sep 27 13:09:17 remember that unless you opt-in to use native python, you use the host python, so don't need to list dependencies Sep 27 13:11:23 rburton: I see that python-native is built in the sysroot, so it is overloading the host python. And I need to ensure if my py module is also included. Sep 27 13:12:55 E.g. import hashlib. How to know if hashlib is included into python-native. And if not, what it's "package" name is. Otherwise it would be hit and miss if all the deps required for a tool is covered.. Sep 27 13:13:46 Is is *probably* included into python-native, and I can easily find that out. But when the package is not built yet, you don't really know where to find things Sep 27 13:14:26 (and it is included) Sep 27 13:22:25 sveinse: python-native is *all* of python Sep 27 13:22:49 sveinse: as i said, python-native is opt-in. you'll notice that python *is not* on the path Sep 27 13:25:10 rburton: Yes, but python is much more than just python itself. E.g. numpy. As for an example, the SDK that our devs are using is containing python: /srv/opt-16.04/poky/1.9-223/sysroots/x86_64-pokysdk-linux/usr/bin/python Sep 27 13:25:28 sure, sdk != native Sep 27 13:26:16 rburton: ok... So why do I make a vsi-native tool then? Sep 27 13:26:25 As in: Sep 27 13:27:11 I want it to easily access the tool from other recipes. And if I specify vsi-natve in depends of the sdk, it will end up there also, right? Sep 27 13:27:22 no Sep 27 13:28:07 you'll need a nativesdk form to be in a sdk that the user can run directly Sep 27 13:28:26 (this is where you use bbclassextend="native nativesdk") Sep 27 13:28:42 right Sep 27 13:28:42 call the recipe vsi.bb, use bbclassextend, sorted. Sep 27 13:31:48 thanks, but my question still remains: Other than oe-pkgdata-util there is no tool for finding which package/recipe/group a file belongs to (without actually building the recipe)? Sep 27 13:33:35 You see, if you are handed a larger python script that imports a lot of modules, how to determine that you have covered all RDEPENDS for it? This applies both to native as well as target Sep 27 13:34:18 grepping and finding and hoping for the best? Sep 27 13:35:04 rdepends python-modules Sep 27 13:35:12 which is a metapackage for all of python Sep 27 13:35:22 without building the recipe you can't tell what gets built Sep 27 13:35:32 i can't tell you from my build what your build generates Sep 27 13:35:35 including numpy or twisted? Sep 27 13:35:43 no, all built-in modules. Sep 27 13:36:12 precisely, so you'd need some knowledge of what modules are built-in and what is not Sep 27 13:36:21 yes, exactly the same as with other distros tbh Sep 27 13:36:35 random python script needs reading to determine what the dependencies are Sep 27 13:37:49 yes, that's easy. Figuring out to what yocto recipe is harder, as the file/module's name might not make any relationship to the recipes name Sep 27 13:37:57 But I get it, there is no index for this Sep 27 13:38:26 assuming you've built everything, oe-pkgdata-tool can search for files Sep 27 13:38:56 and when writing a recipe, recipetool will scan setuptools for dependencies if they're done Properly Sep 27 13:39:41 btw, are there any bitbake target that builds *every* recipe of poky (and meta-openembedded), giving a large coverage? Sep 27 13:39:56 With that we could build a cache to search in Sep 27 13:40:08 sveinse: "world" is pretty big Sep 27 13:41:18 jku: It is. But it is also hard to find what recipes files belong to ahead of building it. Sep 27 13:44:11 sveinse: you can very often transfer your knowledge from your host distro to your yocto based os: if apt-file tells you the package you want is python-numpy, then looking for python-numpy is very likely to give results in poky git (or https://layers.openembedded.org/layerindex/branch/master/recipes/)... Sep 27 13:44:34 "apt-file on debian", I mean Sep 27 13:45:49 I'd propose building a "locate" database or something similar to packages.debian.org, to be able to give an (imperfect) overview of the files built by the layers. Devs often know what file, library or resource they need, but spend a long time finding the appropriate layer/recipe. Sep 27 13:46:21 jku. the oe layer index is very good Sep 27 13:48:16 jku, having a files list would be nice. I do know its different for different configs, but most files are more or less the same across multiple targets, machines and tunes, so it would not be completely misleading. Sep 27 13:48:20 Just my 2 cents Sep 27 13:55:56 Thank you, rburton :D Sep 27 14:07:38 Hi, I'm adding a new MIPS ABI. Got things to mostly work. Except for one last thing. Sep 27 14:07:41 my rootfs doesn Sep 27 14:08:01 my rootfs doesn't have a symlink from /lib/ld.so.1 -> /lib/ld-2.23.so Sep 27 14:08:21 what is the enw ABI? Sep 27 14:08:41 and i've added the tunings to glibc-ld.inc Sep 27 14:08:41 "mipsisa32r6": ["ld.so.1", "FLAG_ELF_LIBC6"], Sep 27 14:08:41 "mipsisa32r6el": ["ld.so.1", "FLAG_ELF_LIBC6"], Sep 27 14:08:43 mips32r6 Sep 27 14:08:54 the symlink would be created by the libc package. The links are installed as part of the soname processing.. Sep 27 14:09:06 soname links are always installed -- links to non-soname are moved to -dev packages... Sep 27 14:09:17 thats a CPU, the ABI is the same -- o32 right? Sep 27 14:09:26 'er.. not CPU - ISA I meant Sep 27 14:09:49 yea sorry. o32/n32 is the same Sep 27 14:09:56 tune comprises a combination of ISA and ABI.. adding a revised ISA is pretty easy -- adding a revised ABI can be more challenging since all of the peices have to go together.. Sep 27 14:10:01 n32 is a MIPS64 ABI Sep 27 14:10:27 is there a way to disable inclusion a package listed in MACHINE_EXTRA_RRECOMMENDS, from local.conf, myimage.bb, or somewhere else ? Sep 27 14:10:31 generally mips32 is o32, MIPS64 is o32, n32 and n64.. (sorry I'm being pedantic, I want to make sure we're using the same terms -- MIPS is complicated enough) Sep 27 14:10:58 MACHINE_EXTRA_RRECOMMENDS_remove = "item" Sep 27 14:11:09 Its necessary to be pedantic :) Sep 27 14:11:17 recommends can also be controlled with other items Sep 27 14:11:36 BAD_RECOMMENDATIONS things to try to filter out of 'recommends' Sep 27 14:11:52 NO_RECOMMENDATIONS = '1' (disable recommends processing) Sep 27 14:11:54 The tuple has changed a bit. That made things a bit tricky. Sep 27 14:11:56 https://wiki.debian.org/Multiarch/Tuples Sep 27 14:12:10 fray: ah, BAD_ is more what I'm looking for, it's a package that does not build Sep 27 14:12:14 mipsel-linux for mips32 Sep 27 14:12:14 mipsisa32r6-linux for mips32r6 Sep 27 14:12:44 build is something different (maybe). If the package does not build, I would recommend blacklisting it to prevent it from being accidently included.. Sep 27 14:12:54 PNBLACKLIST[recipe] = 'Reason for blacklist' Sep 27 14:13:18 someone is shooting -very- close by.. Sep 27 14:13:20 Hmm.. Sep 27 14:13:28 oops wrong channel (I live in the country -- it's hunting season) Sep 27 14:44:46 fray: BAD_RECOMMENDATIONS and MACHINE_EXTRA_RRECOMMENDS_remove and even PACKAGE_EXCLUDE in local.conf all have no effect Sep 27 14:45:06 black list it. The blacklist message will tell you where the dependency is Sep 27 14:48:17 If I use BBCLASSEXTEND = "native nativesdk", I see from grepping the tmp/ files, that it builds it for my MACHINE. If I inherit native, it builds it for native. Why is that? Sep 27 14:50:19 ah, packagegroup-base turns RRECOMMENDS into RDEPENDS, even when they are also in PACKAGE_EXCLUDE of BAD_RECOMMENDATIONS ? Sep 27 14:50:22 s/of/or/ Sep 27 14:53:03 funny, blacklist also prevents the package to be cleaned :) Sep 27 14:55:25 ok, blacklist works, after cleaning the partial build Sep 27 15:35:38 > I'd suggest we put these messages into some log file or somewhere other than the main terminal window as they cause significant concern for the user. So doing nothing isn't an option Sep 27 15:35:52 You're right. Clearly we need to do something. What if we tell the user to stop being such a crybaby? Sep 27 15:35:54 ... hmm. Sep 27 15:36:01 Okay, I concede this may not be a good marketing plan, anyway. Sep 27 15:36:30 with the reproducer from Robert, do you think it's a real problem or just a spurious collision/error message that is recovered? Sep 27 15:38:53 My current suspicion is that we had an actual problem causing failures (the docker thing), but that this form is a harmless(-ish) race condition thing. I'd still like to poke a bit. The lock_held thing is unthreatening; it's the timeouts that were worrisome. Sep 27 15:40:42 I think the answer is probably to try to move the pseudo_debug_logfile() thing WAY up in the code, but still contingent on opt_d. Sep 27 15:41:23 I've not looked at that code in the last few months, after the child error, IS the connection retried, or does the collision cause a problem? Sep 27 15:41:44 I think we retry up to ~50 times, still. Sep 27 15:41:47 if it is retried, then it is a harmless race (in fact one we expect could happen) Sep 27 15:41:48 Not that it comes up much anymore. Sep 27 15:42:04 ya.. so as long as it's retried.. then logging it earlier would fix the real issue.. Sep 27 15:42:37 For some reason I find it necessary to do a bitbake -c do_clean linux-yocto before the right defconfig is applied to it? has anybody else seen this phenomena? Sep 27 15:42:37 Usually happens if I change something and the kernel needs to be recompiled. Instead of the right defconfig in my bbappend. It tries to compile the default Sep 27 15:42:39 So, the client invokes daemon with -d. If we made the logfile switch implicit at that point, I think that would solve it. Sep 27 15:43:01 seems reasonable Sep 27 15:44:07 I am not totally sure, there's some quirks. Sep 27 17:36:47 Do folks see it as reasonable to have a bunch of deploy-only recipes where there only deps are via task dependencies on other do_deploy tasks? **** ENDING LOGGING AT Wed Sep 28 02:59:58 2016