**** BEGIN LOGGING AT Thu Sep 17 02:59:59 2015 Sep 17 05:03:30 hello everyone! Sep 17 05:04:27 I am trying to stream a webcam (logitech c310) from intel edison board that runs yocto linux over wifi. Sep 17 05:05:02 but it is showing an error "Error opening device: /dev/video0 open: No such device or address" Sep 17 05:23:04 first guess - have you made sure the kernel in use provides the features you need? e.g. driver for that particular model, v4l2 infrastructure? Sep 17 05:58:53 If I have a recipe that is using git on branch master (with src set to autorev) will it check for updates? Sep 17 06:20:37 hi.. yes.. I've installed the UVC drivers using opkg install kernel-module-uvcvideo Sep 17 06:41:53 rethna30: then i'd say, inquire further with dmesg, syslog, lsusb and friends. Sep 17 07:22:50 good morning Sep 17 07:26:36 'morning Sep 17 07:43:00 RP: hah, thanks - I can't accept much of the credit for that though Sep 17 08:18:18 hi folks Sep 17 08:18:31 i am having trouble with MACHINE_EXTRA_RRECOMMENDS Sep 17 08:18:53 I have two environments Sep 17 08:19:15 on one a specific package is needed and on the other it is not even available Sep 17 08:19:40 so i used MACHINE_EXTRA_RRECOMMENDS += "f00" Sep 17 08:20:07 but the build fails in the environment where foo isnt available Sep 17 08:20:20 while it succeeds on the other environment Sep 17 08:20:40 the documentation specifically suggests that Sep 17 08:20:51 This variable is similar to the MACHINE_EXTRA_RDEPENDS variable with the exception that the image being built does not have a build dependency on the variable's list of packages. In other words, the image will build if a file in this list is not found. Sep 17 08:21:23 is this a bug or am i doing something wrong Sep 17 08:21:29 ??? Sep 17 08:22:38 In packagegroup-base.bb we have RRECOMMENDS_packagegroup-machine-base = "${MACHINE_EXTRA_RRECOMMENDS}" Sep 17 08:22:54 now if we look at the documentation for RRECOMMENDS Sep 17 08:22:57 it says Sep 17 08:23:54 Packages specified in RRECOMMENDS need not actually be produced. However, a recipe must exist that provides each package, either through the PACKAGES or PACKAGES_DYNAMIC variables or the RPROVIDES variable, or an error will occur during the build. Sep 17 08:24:01 isn't this a conflict Sep 17 08:24:03 ??? Sep 17 08:24:30 abelal: no Sep 17 08:24:52 bluelightning: ok, so please correct my thinking Sep 17 08:25:26 it's the difference between a recipe stating it provides a recipe with the specified name, and and whether the package actually has any contents (if a package is empty, by default it is not written out) Sep 17 08:25:30 er Sep 17 08:25:36 stating it provides a package, I meant to type Sep 17 08:25:51 hmmm Sep 17 08:26:05 that means a recipe must exist at all times Sep 17 08:27:35 bluelightning: ^ Sep 17 08:27:46 effectively yes Sep 17 08:28:05 perhaps you can describe what you're attempting to do? Sep 17 08:28:20 bluelightning: so is there any other way this can be done? Any variable that would help in the scenario Sep 17 08:32:25 bluelightning: and what's the real catch with this variable then? Sep 17 08:32:44 sorry, what do you mean by "real catch"? Sep 17 08:32:51 the practical use? Sep 17 08:33:44 yeah Sep 17 08:34:29 one common example is adding dependencies on kernel modules Sep 17 08:34:46 the functionality may instead be compiled into the kernel instead of the module Sep 17 08:35:11 ahan Sep 17 08:35:22 the kernel always satisfies kernel-module-* as far as bitbake is concerned by way of PACKAGES_DYNAMIC Sep 17 08:35:37 but that does not mean that it will actually produce a module package of that name Sep 17 08:35:49 ah ok Sep 17 08:35:56 and because it's an RRECOMMENDS everything is happy Sep 17 08:36:32 understood Sep 17 08:36:37 bluelightning: THANKS! Sep 17 08:36:51 the other feature of RRECOMMENDS is that you can elect not to install them (on target, or when building the image) by way of BAD_RECOMMENDATIONS or NO_RECOMMENDATIONS Sep 17 08:37:26 but that would only cater recommends, right? Sep 17 08:37:44 not anything from rdepends... Sep 17 08:38:21 absolutely... RDEPENDS are non-optional, that's the idea Sep 17 08:38:43 though you can use things like PACKAGECONFIG to have build-time optional RDEPENDS Sep 17 08:39:13 build-time meaning build-time of the recipe, not the image Sep 17 08:42:45 thanks bluelightning :) Sep 17 08:42:49 np Sep 17 08:42:53 brb Sep 17 10:30:45 bluelightning: is documentation.conf automagically pulled into the manuals somehow? Sep 17 10:31:06 I see scripts that consume that file but their purpose is not clear with a quick skim Sep 17 10:31:17 * joshuagl tagged bluelightning as he authored the script Sep 17 10:31:19 joshuagl: sort of... there's a script to sync values from the manual to the conf files, so the main source is supposed to be the docs Sep 17 10:31:37 so, new variables added to docs not conf file? gotcha Sep 17 10:31:40 joshuagl: there's still some values in the docs side that need fixing and that's where we've been stuck Sep 17 10:31:46 joshuagl: ideally yes Sep 17 10:32:11 bluelightning: ack, thanks Sep 17 10:32:20 if we could tidy up those values and then have the script run on a regular basis that would be ideal Sep 17 14:56:49 I am reading http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#performing-automated-runtime-testing Is there any place with examples of tests? Sep 17 15:04:49 mcfrisk: sounds like we should be aware of that section (http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#performing-automated-runtime-testing). Are we? Sep 17 15:15:07 nine_pt: the tests we ship out of the box can be found in meta/lib/oeqa/runtime/ - hopefully they should serve as examples Sep 17 15:15:23 if we're not drawing adequate attention to those in the manual we ought to be Sep 17 15:18:22 bluelightning: I missed the line: "All test files reside in meta/lib/oeqa/runtime" Sep 17 15:18:26 on documentation Sep 17 15:20:26 ok, great Sep 17 15:20:53 you can add your own tests in your own layer too (which it also mentions) Sep 17 15:25:30 my current version don't have test (too old need to update) I am thinking using the new one, making the tests external and run on images deployed over older version. One thing at time, first test what we have next update poky. Do you see any problem with this approach? Sep 17 15:30:47 nine_pt: hmm, I'm not sure if we made any changes to other parts of the code in order to support this, we may well have Sep 17 15:32:11 what I was expecting is the standalone version of tests work with boards, independent of poky that generate the image. Sep 17 15:43:41 nine_pt: the way we implemented it was that the tests run on the host and interact with the target over ssh Sep 17 15:44:41 nine_pt: additionally some of the tests need to make use of artifacts generated by the build system, so it kind of made sense to have them executed within the build system, though there isn't anything preventing you from having the tests run on a separate test controller machine than the machine running the build Sep 17 15:45:10 nine_pt: the reason we did it that way was that we wanted to run some tests e.g. involving package feeds where we needed to do things on both the host side and the target side in order to execute the test Sep 17 15:45:34 we did add a mechanism to export the tests though Sep 17 15:55:15 hey guys i am having some issues with bitbake Sep 17 15:55:15 it seems to be crashing Sep 17 15:55:15 when i try to compile an image, any one know a solution? Sep 17 15:55:18 or any one come across something similar? Sep 17 15:56:24 dasabhi: you'll need to give more context than that Sep 17 15:57:19 bluelightning: thanks for the explanation, I will try it and see if work Sep 17 15:57:24 works Sep 17 15:57:30 one more time, thanks for the time Sep 17 16:01:12 bluelightning: hey! are you coming to ELCE ? Sep 17 17:04:53 Marex: hey, indeed I am Sep 17 17:06:46 and you? Sep 17 17:07:17 :-) Sep 17 17:10:07 otavio: will you also be there? Sep 17 17:11:31 otavio: will you ? Sep 17 17:11:37 bluelightning: no :-( Sep 17 17:11:39 bluelightning: cool, I'll be there :) Sep 17 17:11:48 otavio: that sucks, I wanted to torture you IRL ;-) Sep 17 17:11:51 otavio: ah ok, that's a shame Sep 17 17:12:15 Marex: kkk Sep 17 17:12:18 bluelightning: indeed Sep 17 17:12:22 maybe next year Sep 17 17:12:42 otavio: would be nice to have you join the #opticalexperiments Sep 17 17:12:51 Marex: ohhh yeah! Sep 17 17:12:52 kkk Sep 17 17:12:57 \m/ Sep 17 17:13:56 bluelightning: there isn't going to be a yocto day this year, huh ? Sep 17 17:14:10 Marex: yes, dev day confirmed ;-) Sep 17 17:16:09 otavio: meh, I'd have to re-book my plane ticket, so I guess I'll only attend the morning session Sep 17 17:16:39 Marex: U-Boot will have the meeting as well? Sep 17 17:17:09 otavio: I don't know honestly, try asking your big friend Wolfgang :-) Sep 17 17:17:38 Marex: no; he is too hard to deal with, and I am in good mood today Sep 17 17:17:39 kkk Sep 17 17:18:39 otavio: your 'kkk' reminds me of that 'indemnification' from hackles :) Sep 17 17:19:10 :) Sep 17 17:19:21 http://hackles.org/cgi-bin/archives.pl?request=352 this one Sep 17 17:22:02 hehe Sep 17 17:24:02 LOL Sep 17 17:32:46 i ran into problems while compiling for raspberry2 Sep 17 17:32:53 http://pastebin.ca/3163780 Sep 17 17:33:26 am i doing something wrong? Sep 17 17:34:08 This reminds me: http://openembedded.org/wiki/OEDEM_2015 Sep 17 17:39:02 there is a error right after start of bitbake saying, that two bb files would like to provide virtual/mesa (mesa and mesa-gl) Sep 17 17:39:14 how to deal with this? Sep 17 17:39:33 you need a preferred provider line to pick the one you want Sep 17 17:39:41 are the any notes in meta-rpi about this? Sep 17 17:43:53 mh, i have to search. i am new to this... Sep 17 17:47:28 http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/README Sep 17 17:47:37 is a starting point, but I do not see the answer there Sep 17 17:48:29 i found this: https://lists.yoctoproject.org/pipermail/yocto/2015-April/024488.html Sep 17 17:51:25 but i am not shure where to put in the lines Sep 17 17:51:42 Hello! I'm having some trouble with an autotools-based package. It's not finding a header file, but the file exists in my sysroot: http://pastebin.ca/3163811 Sep 17 17:54:00 aport: I'd recommend having a look at the configure script and config.log to determine where it's really looking (and perhaps how to make it look in the right place) Sep 17 17:55:44 where is the config.log stored? Sep 17 17:56:32 Nevermind, I found it. Thank you bluelightning Sep 17 17:57:37 Crofton|work: i found the rpi-default-providers.inc Sep 17 17:58:20 and is seems to contain the lines Sep 17 17:59:07 bitbake -e something | grep ^PEFERRED_PROvIDER Sep 17 17:59:14 and see what it is really set to Sep 17 18:02:15 http://pastebin.ca/3163832 Sep 17 18:03:05 this are the two error messages Sep 17 18:04:04 KvH: are you trying to build clutter? It pulls in vanilla mesa which creates this conflict Sep 17 18:04:39 aport: it is fido Sep 17 18:05:00 KvH: I'm working with fido on the rpi right now too Sep 17 18:05:21 mh Sep 17 18:05:55 AFAIK Clutter/Cogl pulls in vanilla mesa instead of honoring the preferred provider which should be mesa-gl and userland Sep 17 18:06:02 I don't know if other packages do it too Sep 17 18:07:03 I solved this with a bbappend for cogl which clears ERDEPENDS_GL and ERDEPENDS_GLES2 Sep 17 18:07:34 aport: i mh, iam new to this and do not really understand :) Sep 17 18:07:51 KvH: what are you trying to build? Sep 17 18:08:08 aport https://github.com/Nuand/bladeRF/wiki/Creating-Linux-based-Embedded-System-Images-with-Yocto Sep 17 18:08:31 aport: gnuradio-demo-image Sep 17 18:10:58 KvH, did you try removing tmp-eglibc? Sep 17 18:12:21 Crofton|work: how to do that (what is tmp-eglibc? a package?) Sep 17 18:13:06 you must think i am dumb or something Sep 17 18:13:24 but this are my first steps with this... Sep 17 18:14:25 i wiped tmp/ completely a few times as bitbake suggested it, but it has not helped Sep 17 18:20:16 in your build directory, there is a tmp-eglibc directory, that is the one bitbake means Sep 17 18:30:42 no Sep 17 18:31:06 there is no such file. i did a find over the whole directory tree Sep 17 18:48:50 KvH, in your build directory,m where you run bitbake, r un ls Sep 17 19:29:36 Crofton|work: kaback@ThinkPad-T500:~/builds/build/sdr$ ls Sep 17 19:29:36 bitbake.lock cache conf sstate-cache tmp Sep 17 19:29:36 kaback@ThinkPad-T500:~/builds/build/sdr$ Sep 17 19:30:00 (bitbake is running) Sep 17 19:46:24 ls Sep 17 20:17:06 hello i am getting errors trying to compile a kernel using bitbake Sep 17 20:17:12 i keep seeing the error Sep 17 20:17:19 failed to fetch URl.... Sep 17 20:17:35 and i see this repeating like 6 times Sep 17 20:17:48 any one else come across something similar? Sep 17 20:18:58 dasabhi: means "cannot download that file" Sep 17 20:19:47 Marex: do you know the fix for this? Sep 17 20:21:42 there is no warning about missing checksum? Sep 17 20:42:12 ok, for now i have to go to bed. i am still fighting with mesa on raspberrypi2 Sep 17 20:42:20 ERROR: Task 393 (/home/kaback/builds/poky-fido-1.8/meta/recipes-graphics/mesa/mesa_10.4.4.bb, do_packagedata) failed with exit code '1' Sep 17 20:46:09 dasabhi: fix the remote server probably :b Sep 17 21:11:27 dangit, forgot to ask paul about https://github.com/openembedded/openembedded-core/compare/openembedded:master...kergoth:scriptutils-log-improvements before he took off, will have to remember to tomorrow. not sure it's ready for submission yet Sep 17 23:29:13 does any one here know which version of git yocto needs to run? Sep 17 23:29:28 bitbake won't compile a kernel because it doesnt like the version i have. Sep 17 23:30:38 hmm, good question, we should probably state that clearly in the docs if we don't already, and ideally add a version check to bitbake's git fetcher.. Sep 17 23:40:09 kergoth: well can you point me to a doc that can tell me the version i need? Sep 17 23:48:02 So did Intel do a good job with their version of yocto? 1.7.2 - or did Intel change it alot and it's completely different? Sep 17 23:48:07 Does yocto try a pull on each build when using autorev? Sep 17 23:51:09 xulfer: yes Sep 17 23:51:30 at parse time it contacts the remote server to map the branch name to the commit for autorev, then that's used to fetch and checkout in the later tasks Sep 17 23:51:48 Ah okay. Seemed like it wasn't. Sep 17 23:52:13 I thought maybe it was just skipping it since it already considers it fetched. So I guess I don't need to force another fetch then. Sep 17 23:52:14 remember to include SRCPV in your PV Sep 17 23:52:21 otherwise it won't re-run the fetch tasks when srcrev changes from autorev Sep 17 23:52:30 Ohhh. Maybe that's it Sep 17 23:52:51 it's a common issue, we need to fix it so do_fetch depends on SRCREV directly in certain cases, rather than just not re-running do_fetch when srcrev isn't in PV Sep 17 23:52:54 imo Sep 17 23:54:02 Would be nice yeah. But at least I know what my issue is now. Thanks. Sep 17 23:54:24 np Sep 17 23:54:43 either that or this needs to go in an FAQ :) Sep 17 23:55:37 Odd, gettext-minimal-native is in the shadow configuredeps, yet there are no gettext-minimal-native macros in aclocal-copy Sep 17 23:55:49 * kergoth digs further into aclocal_copy_aclocals in autotools.bbclass Sep 18 00:05:21 and a fresh do_configure copies the files fine, i suspect a race Sep 18 00:05:40 * kergoth tries again Sep 18 00:08:30 sometimes i wish bitbake handled REPLACES, for cases where one recipe is a superset of another, but i can see that causing possible problems with the sysroot content changing under something that depends on the files Sep 18 00:08:31 hmm Sep 18 00:17:33 kergoth: So I should just throw AUTOREV into PV as well? Sep 18 00:17:45 no, as i said, SRCPV goes there Sep 18 00:17:53 it's SRCREV-based, which already includes autorev as appropriate Sep 18 00:18:00 e.g. PV .= "+git${SRCPV}" Sep 18 00:18:05 see the metadata, there are lots of examples Sep 18 00:18:24 ah okay. thanks again. Sep 18 00:18:31 np Sep 18 00:20:21 aha, and shadow failed again. if i bitbake -c configure shadow, it works, but a bitbake core-image-minimal fails in do_configure for shadow Sep 18 00:20:59 something must be mucking around with the manifests, because configuredeps is correct in the failed case, and bitbake -c configure shadow after the failure continues to fail Sep 18 00:21:27 er, check that, it just worked running configure explicitly after hte failure, bah Sep 18 00:31:56 aha, got it Sep 18 00:32:53 in the non-gplv3 case, target gettext's macros aren't available, since we don't want the old gplv2 gettext macros cluttering up things. the problem with that is, aclocal_copy_aclocals only picks up direct native deps of target recipes, and gettext-native doesn't provide the macros, gettext-minimal-native does, which is depended on by gettext-native. Sep 18 00:33:10 adding gettext-minimal-native to DEPENDS_GETTEXT, so it gets included explicitly and directly, resolves the issue Sep 18 02:39:31 khem: thanks for the nios2 review ;-) Sep 18 02:55:50 ugh, what the hell Sep 18 02:55:54 we remove incompatible licenses from the manifest Sep 18 02:55:58 this is a *terrible* idea Sep 18 02:56:23 if i set gplv3 as not allowed, and a gplv3 package somehow gets into the image, the last thing i want the code to do is *lie* to me about it, hiding the incompatible licenses from the manifest Sep 18 02:56:36 no, the opposite, i want the build to stop if something i say isn't allowed ends up in my filesystem Sep 18 02:57:01 * kergoth adds a plan of attack to fix this properly Sep 18 02:57:27 * kergoth adds todo to open a bug tomorrow Sep 18 02:58:40 This boggles my mind, that we'd do this. it's a licensing-related lawsuit waiting to happen Sep 18 02:58:42 * kergoth rolls eyes **** ENDING LOGGING AT Fri Sep 18 02:59:58 2015