**** BEGIN LOGGING AT Fri Apr 01 02:59:58 2016 Apr 01 09:04:04 Hi all. Could someone elaborate the VIRTUAL_RUNTIME var a little more? There's virtually no documentation neither in the mega manual nor in the bb manual :/ Apr 01 09:04:48 I'm trying to figure out, why meta/recipes-connectivity/avahi/ is still installing an init-script, although i've got VIRTUAL_RUNTIME_initscripts = "" :/ Apr 01 09:31:51 i just learned that package.bbclass adds a (>= ) requirement to automatically added package dependencies, though not always from looking at the code. when wouldn't it get added? Apr 01 09:35:38 Ulfalizer: Hm not sure but from tracing the SC of package.bbclass it seems it's comming from ASSUME_SHLIBS Apr 01 09:37:27 https://github.com/openembedded/openembedded-core/blob/master/meta/classes/package.bbclass#L1685 ver_needed > shlib_provider > lib_ver > dep_pkg > e > assumed_libs > d.getVar('ASSUME_SHLIBS', True) Apr 01 09:40:14 thanks. maybe it's just when it can't find the lib-to-package mapping, for whatever reason. ASSUME_SHLIBS seems to be a hint. Apr 01 13:24:26 Newbie here... I don't feel comfortable editing my build/conf/bblayers.conf. I shouldn't commit that file, as it contains absolute paths, depending on my system. If I want to build the image elsewhere, I'll have to reconfigure that file for that specific system, right? Apr 01 13:24:49 How can I make it so that when the init scripts get sourced, the bblayers get configured automatically? Apr 01 13:26:10 rubdos: something like this? http://git.projects.genivi.org/?p=genivi-demo-platform.git;a=blob;f=gdp-src-build/conf/bblayers.conf;h=66b2f26e5dafbfed89f8d2b102913c7701ba3926;hb=refs/heads/qemux86-64 Apr 01 13:27:20 seems reasonable. You have a file somewhere in your scripts that copies over that file to build/conf? Apr 01 13:27:27 halstead: was the openembedded-commits hook changed to send only the "digests" or is there some more complicated logic which decides if it will send individual patches or only the digest? Apr 01 13:28:03 I have a feeling that yocto merely is a bunch of prefabbed bash scripts around openembedded and bitbake, right? Apr 01 13:32:01 rubdos: technically, yocto is an organisation. most of the work done by yocto is done in oe-core/bitbake Apr 01 13:32:16 but yocto also provides a ton of recipes and infrastructure around oe Apr 01 13:32:33 oh okay. I probably meant to say "poky" then :) Apr 01 13:33:06 poky is a distro for openembedded, just like angstrom is... i.e it's a usefull pre-configuration for building stuff Apr 01 13:34:07 I see :) Apr 01 13:35:00 I think I was more of expected "the Rails way"; something like convention over configuration, or something like that. Anyhow, it's useful in any case :) Apr 01 15:39:13 RP: will 2.2 be branched soon, after M4, or after release? is the branch point something covered in the release process, or is it unspecified? Apr 01 15:44:34 kergoth: I tend to branch fairly late as it only encourages people to send patches for master rather then concentrating on the release Apr 01 15:45:03 kergoth: release date is at the end of the month so I'd guess at a couple of weeks but there isn't a fixed defined point Apr 01 15:45:05 yeah, I figured, that makes sense. was just curious about whether that late point is defined, or if it varies Apr 01 15:45:15 okay, thanks, that's what i was wondering Apr 01 15:45:51 i'm starting to understand why linus has defined merge times, though that'd be hard to pull off without his lieutenants to gather changes Apr 01 15:45:54 heh :) Apr 01 15:47:42 kergoth: the feature freeze point does drive me completely insane every time around :/ Apr 01 15:48:03 kergoth: There are at least a few people who do help gather the patches... Apr 01 15:49:07 yeah, i know saul does his consolidated merges, and ross does his mut stuff Apr 01 17:22:20 someone knows where is the .templateconf and how can I change it? Apr 01 17:23:10 on the yocto manual only says that I must set the TEMPLATECONF var in the .templateconf, but the templateconf is inside the poky repository Apr 01 17:32:41 my problem is that poky sets the path starting from the OEROOT that points to poky path Apr 01 17:32:54 there is a way to start from the updir? Apr 01 17:35:27 igor3: TEMPLATECONF can be set however you like, it doesn't have to be set via .templateconf Apr 01 17:35:47 i.e. at mentor graphics, we have our own setup environment script in our layer which sets it (among other things) and then sources the default scripts Apr 01 17:36:14 Today I learned that there is a bug in the variable assignment tracking/display. Apr 01 17:36:32 hummm... but the OEROOT will still pointing to poky path, it is the default? Apr 01 17:36:47 Which is that if you're looking at gdb's PACKAGECONFIG, the fact that PACKAGECONFIG[python] exists means that the tracker thinks PACKAGECONFIG is a python value. Apr 01 17:37:10 seebs: ah, yes, i've seen that before too. nature of the beast, we're conflicting namespaces Apr 01 17:37:14 igor3: why is that a problem? Apr 01 17:38:12 I'm trying to remove readline for mingw, and failing, because the PACKAGECONFIG[readline] is overriding anything else. And because I can't track stuff, I can't debug this well. I'm temporarily renaming the flag to [py] in my copy. Apr 01 17:38:27 I want to set my own bblayers.conf with the path of my layer, but the OEROOT isnt pointing to my layer, so I have to put ../path Apr 01 17:38:42 it does not seems to be normal Apr 01 17:39:52 its the default if you want to create your own bblayer.conf? setting the paths with "../"? Apr 01 17:42:08 i don't really see why that's a problem. setting paths relative to the core seems quite reasonable to me Apr 01 17:43:16 seebs: renaming it in general seems like a good idea. we might want to add a sanity check. if PACKAGECONFIG[python] exists, error. (or func, or doc, or.. :) Apr 01 17:45:19 nice, thank you kergoth Apr 01 17:47:16 I am not sure there's any other cases, and it makes SENSE to name it "python", it's just that we're overriding the flag namespace for two unrelated functions Apr 01 17:48:14 Well, a lot more than two, probably. Apr 01 17:49:29 ... Apr 01 17:49:42 okay so for reference, i just spent something like an hour debugging my inability to control PACKAGECONFIG as expected... Apr 01 17:49:50 Because I was running my builds with SDKMACH=i686-mingw32 Apr 01 17:49:56 rather than SDKMACHINE=i686-mingw32 Apr 01 17:50:13 Congratulations to me, I have successfully april-fools-pranked myself, apparently. Apr 01 17:59:55 seebs: this is just one of many cases where we needed a dictionary and abused flags to get one Apr 01 18:00:03 downside to the current file format Apr 01 18:00:27 we could use the variable name namespace, but then there'd be no way to get a list of available packageconfigs without iterating over every key in the datastore.. Apr 01 18:00:29 heh Apr 01 18:03:26 Yeah. We have a similar problem with the massive overloading of _. Apr 01 18:03:34 *thinks* Apr 01 18:08:21 overloading of _? where? Apr 01 18:10:21 kergoth: how are flags implemented internally? with a dictionary on each variable? Apr 01 18:12:56 We use _ for overrides, but also for special things like append/remove, and also often as just part of names. Apr 01 18:13:19 You can't make an override named "append". :) Apr 01 18:13:33 We had a really interesting behavior once involving "OVERRIDES_append = ..." Apr 01 18:13:33 ah, i see what you mean now Apr 01 18:13:41 heh Apr 01 18:13:53 It was pretty much nondeterministic, except that on any GIVEN system/build/set-of-layers, it seemed to be consistent. Apr 01 18:14:08 But we had at least one thing using that thing in an override, which worked in one environment and not in another. Apr 01 18:16:31 unrelated question, but do you know if any reparsing of files is involved in BBCLASSEXTENDS? is it still parsing once but mucking about with variable values afterwards? Apr 01 18:16:50 some uses of := together with BBCLASSEXTEND might be problematic in that case i guess :/ Apr 01 18:17:20 Ulfalizer: no reparsing, no Apr 01 18:17:28 yeah, that's what i guessed Apr 01 18:17:30 thanks Apr 01 18:18:20 the metadata is copied for each variant, then the class is programmatically inherited, and the metadata re-finalized Apr 01 18:18:33 see _create_variants() & friends in bitbake/lib/bb/parse/ast.py Apr 01 18:18:58 kk Apr 01 18:35:53 Hi guys. Can I fetch source just for one package with bitbake fetch? For example, I want only the content of linux-dummy.bb Apr 01 18:36:52 Maybe this is not the best example. Better would be linux-yocto_3.14.bb:) Apr 01 18:41:13 bitbake -c fetch Apr 01 18:43:17 kergoth: ERROR: Nothing PROVIDES 'linux-yocto_3.14.bb'. Close matches: linux-yocto Apr 01 18:43:27 bitbake doesn't accept a filename, it never has Apr 01 18:43:34 read the bitbake manual, yocto manuals, or bitbake --help Apr 01 18:43:44 it accepts a recipe name or other provider Apr 01 18:43:47 bitbake -c fetch virtual/kernel Apr 01 18:43:50 bitbake -c fetch linux-yocto Apr 01 18:45:49 ok, thanks. It is working now. Apr 01 18:47:54 however, I have another problem, because it is downloading very slow. Like 100 kbps. This is strange, because when I do "git clone git://git.yoctoproject.org/linux-yocto-4.1.git" it is downloading very fast, like 12Mbps Apr 01 18:49:30 when I go to http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.1 and click on " linux-yocto-4.1-4.1.15.tar.gz" for example, it is downloading with similar speed (like 100 kbps) Apr 01 18:49:51 kergoth: can I fix it somehow? Is there any mirror of git.yoctoproject.org? Apr 01 19:07:57 Greetings, I'm hoping for some advice on an issue that I realize may not have an easy solution, but I need a strategy for going forward. Apr 01 19:08:58 I believe I'm experiencing an issue related to python3 not properly installing on the target. Apr 01 19:09:43 Nutshell example: Apr 01 19:09:44 The following command, Apr 01 19:09:44 bitbake -e python3 |grep \^PACKAGES= Apr 01 19:09:44 produces output in which I locate Apr 01 19:09:44 "python3-math", Apr 01 19:09:44 ​​among others. Apr 01 19:09:46 Added to the conf/local.conf is: Apr 01 19:09:48 #python3 Apr 01 19:09:50 IMAGE_INSTALL_append += " \ Apr 01 19:09:52 ... Apr 01 19:09:54 python3-math \ Apr 01 19:09:58 ... Apr 01 19:10:00 " Apr 01 19:10:02 ​On the target, I run Apr 01 19:10:04 python3 Apr 01 19:10:06 import math Apr 01 19:10:08 > ImportError: No module named 'math' Apr 01 19:13:00 Looking at the manifest, math should be placed in the python3-core package, and that should be installed along with others in core. Apr 01 19:14:12 Implying that the step taken above to explicitly install python3-math package should not be necessary. Apr 01 19:14:49 sadly I have no python3 things to try Apr 01 19:15:11 I assume you looked at where the modules are? Apr 01 19:17:02 Yes, unfortunately it's a behaviour I'm showing with some python modules as well. The successful work around up to this point has been to include the packages explicitly in IMAGE_INSTALL_append, but as you can see that measure failed for this case (and others), and it doesn't sit well that this doesn't seem to be the way I shoould necessarily be going about it.) Apr 01 19:18:11 Taken from another direction, if I locate the rpm built for python3-math, transfer it to the target, then attempt to install, the target will claim that the package is already installed. Apr 01 19:19:38 see the content of python-math.rpm, maybe the math implementation isnt in the rpm Apr 01 19:22:04 hehe, made a Makefile with PHONY: all and all: bitbake ... Apr 01 19:22:05 :P Apr 01 19:22:36 I shall check Apr 01 19:28:01 Alright, so please forgive the copy-paste spam action, but: Apr 01 19:28:21 SUMMARY_${PN}-core="Python interpreter and core modules" Apr 01 19:28:21 RDEPENDS_${PN}-core="${PN}-lang ${PN}-re ${PN}-reprlib ${PN}-codecs ${PN}-io ${PN}-math" Apr 01 19:28:21 FILES_${PN}-core="${libdir}/python3.3/__future__.* ${libdir}/python3.3/_abcoll.* ${libdir}/python3.3/abc.* ${libdir}/python3.3/copy.* ${libdir}/python3.3/copyreg.* ${libdir}/python3.3/ConfigParser.* ${libdir}/python3.3/genericpath.* ${libdir}/python3.3/getopt.* ${libdir}/python3.3/linecache.* ${libdir}/python3.3/new.* ${libdir}/python3.3/os.* ${libdir}/python3.3/posixpath.* ${libdir}/python3.3/struct.* ${libdir}/python3.3/warnings.* ${libdir}/python3.3/ Apr 01 19:28:21 site.* ${libdir}/python3.3/stat.* ${libdir}/python3.3/UserDict.* ${libdir}/python3.3/UserList.* ${libdir}/python3.3/UserString.* ${libdir}/python3.3/lib-dynload/binascii.*.so ${libdir}/python3.3/lib-dynload/_struct.*.so ${libdir}/python3.3/lib-dynload/time.*.so ${libdir}/python3.3/lib-dynload/xreadlines.*.so ${libdir}/python3.3/types.* ${libdir}/python3.3/platform.* ${bindir}/python* ${libdir}/python3.3/_weakrefset.* ${libdir}/python3.3/sysconfig.* ${li Apr 01 19:28:26 bdir}/python3.3/_sysconfigdata.* ${libdir}/python3.3/config/Makefile ${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h ${libdir}/python${PYTHON_MAJMIN}/collections ${libdir}/python${PYTHON_MAJMIN}/sitecustomize.py " Apr 01 19:29:01 From the manifest.inc file for python3. Apr 01 19:29:38 python3-core appears to have the RDEPENDS...${PN}-math" Apr 01 19:31:07 Viewed on the target, the /usr/lib shows the *.py files that should be there according to what is inside the rpm for -core. Apr 01 19:31:28 But missing is, say, random.py from the python3-math rpm. Apr 01 19:32:51 So as a side question, am I misunderstanding the manifest, that core SHOULD include math? Apr 01 19:34:52 What might account for explicitly including the python3-math package in the image install, but the files in the rpm not being on the target image? Apr 01 19:35:20 Apologies and gratitude to all who've read so far... Apr 01 19:36:54 how do you determine that the python3-math package is not on the target image? Apr 01 19:36:59 maybe it is, but the content is wrong? Apr 01 19:37:11 did you check the image manifest for python3-math? Apr 01 19:37:17 did you check what's in the python3-math package? Apr 01 19:50:26 Yes, to most of those questions. Apr 01 19:50:28 First: Apr 01 19:51:03 If I look at the rpm on the build host, inside is /usr/lib/python3.3/random.py Apr 01 19:51:54 That file is not located on the target, implying that the package did not install properly (but smart on the target claims that it was installed) Apr 01 19:52:47 Second: Correct, I think that the content is wrong for this package. As mentioned, in the rpm is random.py, but the manifest indicates there should be more files in there: Apr 01 19:52:54 FILES_${PN}-math="${libdir}/python3.3/lib-dynload/cmath.*.so ${libdir}/python3.3/lib-dynload/math.*.so ${libdir}/python3.3/lib-dynload/_random.*.so ${libdir}/python3.3/random.* ${libdir}/python3.3/sets.* " Apr 01 19:53:23 "sets" for instance Apr 01 19:53:51 if the .so's arent included, likely they didn't come out of the python build. see teh logs of the python build Apr 01 19:58:04 Please forgive me, do you mean that some step might be skipping a few of the .so files when building, resulting in an incomplete installation (that does not cause overt errors elsewhere in the build process)?) Apr 01 20:00:59 As a side, if I navigate to /buildhistory/images/intel_coreiu7_64/glibc//image-files/ there's some output like: Apr 01 20:01:33 installed-packages.txt shows python3-math-3.3.3-r1.0.corei7_64.rpm. Apr 01 20:01:44 yes, it's entirely possible that python disabled emission of some module without failing the build Apr 01 20:01:52 i've seen it before Apr 01 20:01:56 smiller6: Yes, that's what he's indicating. What could also be happening is that due to configuration, the generated files have different names, and the FILES_${PN}-math list doesn't match anymore Apr 01 20:02:16 In that case the files would probably land in some catchall package at the end Apr 01 20:04:26 "and the FILES_${PN}-math list doesn't match anymore" sounds spooky... Apr 01 20:05:11 FILES_${PN} is just a list of glob expressions; everything that matches gets moved into this package. Everything else, doesn't. Apr 01 20:05:27 indeed. having a pattern there taht doesn't match anything is non-fatal Apr 01 20:05:34 If there's a more generic expression for a package further in $PACKAGES, that may not be fatal Apr 01 20:05:55 Only if none of the globs match a file and it doesn't get packaged, you'll get an error Apr 01 20:05:59 Alright, that's fair. Apr 01 20:06:56 If you don't have rm_work enabled, check ${WORKDIR}/packages-split for your python3 build Apr 01 20:07:10 And see if the missing files are in there somewhere Apr 01 20:14:00 Apologies, I don't see a packages-split directory. But if I head to the /image/usr/lib/python3.3 in the python3 WORKDIR, I do see a number of files in there that should be on the target, but are not. Apr 01 20:14:42 It's true that files in the /image dir ultimately are what gets written to the rootfs? Apr 01 20:28:00 No Apr 01 20:28:14 image is split into packages (which should be written to packages-split) Apr 01 20:28:20 and those packages then get installed on the target Apr 01 20:28:36 So if the files are in image, but not on your target, then the packaging is your culprit Apr 01 21:04:52 RP: around ? Apr 01 21:05:49 I am looking for code which sets up symlinks for toolchain in SDK between uclibc and glibc candian-cross compilers in install Apr 01 21:06:19 I need to hook clang into this symlinking Apr 01 21:14:37 As an aside, thanks to each who've helped so far. I've clearly got some more investigation to do... Apr 01 21:50:39 RP: cross_canadian_bindirlinks() is what I was looking for **** ENDING LOGGING AT Sat Apr 02 02:59:58 2016