**** BEGIN LOGGING AT Fri Jul 15 02:59:58 2016 Jul 15 06:24:52 hello Jul 15 06:25:33 is anyone familiar with sabre auto board Jul 15 06:25:35 ? Jul 15 06:33:22 how can i check if yocto see my mouse or keyboard? Jul 15 06:59:30 good morning Jul 15 07:00:13 good morning Jul 15 07:00:37 akoc: list the content of /dev/input on the target Jul 15 07:01:21 by-path event0 event1 event2 event3 event4 mice mouse0 Jul 15 07:01:29 it shows these Jul 15 07:01:44 akoc: looks like mouse is present Jul 15 07:02:22 I am using wireless mouse can it be problem Jul 15 07:02:42 ? Jul 15 07:03:53 akoc: I never tried a wireless mouse with embedded, but I guess is fine Jul 15 07:04:08 try cat /dev/mouse0 Jul 15 07:05:20 it shows some result when deplug mouse and keyboard Jul 15 07:05:20 *same Jul 15 07:08:02 cat: /dev/mouse0: No such file or directory Jul 15 07:10:46 akoc: I have a beagleBone on my desk now, tried this, do the same: http://pastebin.com/gcMgBa3T Jul 15 07:21:06 sorry for late reply my internet connection crashed Jul 15 07:21:13 I got only this : random: nonblocking pool is initialized Jul 15 07:21:27 and terminal stays buys Jul 15 07:21:39 *busy Jul 15 07:22:25 akoc: look at dmesg Jul 15 07:22:57 what kind of line i should llook for Jul 15 07:23:05 there is a huge list here Jul 15 07:26:38 akoc: something saying 'mouse' like here http://pastebin.com/gcMgBa3T Jul 15 07:27:13 akoc: boot the board, and plug in the mouse after the boot Jul 15 08:18:08 http://pastebin.com/DwrTn0Jf Jul 15 08:19:15 joshuagl, khem - thanks for responses about errors.yoctoproject.org / syntax-highlighting logs. Yes at least it does a little formatting but it might not be more than I'll just redo it. In case I find/create syntax highlighting I'll make it known but likely it won't happen. Jul 15 08:21:04 ok, found the code for the error web on git.yp.org - thanks. Jul 15 08:25:23 that is quite neat Jul 15 08:26:21 For recipes that track SCMs, do you by convention always use myrecipe_ver.bb ? Or can you omit the _ver suffix? Jul 15 08:26:54 sveinse: personally, depends on the recipe. if its tracking releases which happen to be in git then i prefer to use _1.2.3.bb Jul 15 08:27:21 but you can drop the _ver and put PV in the recipe if you're basically just tracking specific commits Jul 15 08:30:35 also, in a layer, the docs says, recipes-* should be used. But what is * usually? I added our application under recipes-system Jul 15 08:30:57 literally whatever you want Jul 15 08:31:13 so its for grouping only Jul 15 08:31:15 yeah Jul 15 08:31:32 you don't even need a recipe-* structure, just change layer.conf if you want to remove it Jul 15 08:31:50 yeah Jul 15 08:35:31 I've go a long RDEPENDS list (which were found by the QA checks), would be safe to assume that the same package names should go into the DEPENDS list, or might they be named differently and/or that you should use inherit or require for some of them? Jul 15 08:47:15 hello again Jul 15 08:47:21 :) Jul 15 08:48:32 sveinse: no, RDEPENDS = output package names ( ipk/rpm names) DEPENDS have recipe names or virtual Jul 15 08:48:34 names Jul 15 08:48:36 How can i disable login screen(it looks like terminal) from monitor Jul 15 08:49:01 akoc: disable the console Jul 15 08:49:42 how can disable it? Jul 15 08:49:48 *I Jul 15 08:51:28 I have a spesific setup file so I can't build it from scratch atm. Jul 15 08:51:53 is there a way of doing it from terminal Jul 15 08:52:58 gunnarx: we have syntax highlighter for cgit on git.openembedded.org but its quite a hog for CPU Jul 15 08:53:23 ok. implementation language? Jul 15 08:53:57 hang on, for cgit? syntax highlighting source code then? Jul 15 08:54:56 akoc: dont spawn getty on console you can control it by /etc/inittab assuming you are using sysvinit or busybox-init Jul 15 08:55:06 gunnarx: yes Jul 15 08:55:15 brb Jul 15 08:55:38 * khem this frappuchino late at night was not a good idea Jul 15 08:58:43 khem: I have this on inittab Jul 15 08:58:44 http://pastebin.com/avgqyGmp Jul 15 09:01:25 akoc: is it yoct ? Jul 15 09:01:37 OE based Jul 15 09:01:50 actually it has some more lines Jul 15 09:01:51 http://pastebin.com/fsD7Hjv5 Jul 15 09:02:05 yes this is yocto Jul 15 09:02:24 based Jul 15 09:03:24 you already have #mxc3:12345:respawn:/sbin/getty 115200 ttymxc3 disabled Jul 15 09:03:35 so may be you should comment out Jul 15 09:04:13 1:2345:respawn:/sbin/getty 38400 tty1 Jul 15 09:04:50 When I start from a completely empty build, and write bitbake myrecipe it will only build and populate the packages/recipes required for the dependencies, right? Jul 15 09:06:23 khem, ok. my question was only about highlighting bitbake console output a bit when it is converted to HTML anyway. Make the logs a little nicer to look at. I suppose no one has made any rules for highlighting that :) Jul 15 09:09:17 there was a VIM plugin Jul 15 09:09:28 basically hightlight compiler error output Jul 15 09:09:41 now a days compilers do it themselves on rich terminals Jul 15 09:17:52 sveinse: if recipes are correct then that should be correct, yes. Required tools are built first, then your target dependencies. Jul 15 09:36:09 is the openembedded-devel mailinglist moderated? or can i send patches without being subscribed? Jul 15 09:53:05 mwalle: yes its moderated if you're not a subscriber, but you can subscribe and then turn off delivery of mails. Jul 15 09:55:54 rburton: ah good to know, thanks Jul 15 09:56:18 unfortunately, i've already send the patch ; Jul 15 10:00:15 hi all , How to remove the Linux password entry screen Jul 15 10:01:02 with debug-tweaks in image features you get a root account with no password Jul 15 10:45:42 Hmm, when I build my recipe from scratch it fails with "Could not find qmake configuration file linux-oe-g++.", but I find it in ./sysroots/x86_64-linux/usr/lib/qt5/mkspecs/linux-oe-g++, almost next to qmake itself. Jul 15 10:50:07 does yocto have a tool that can show which package that provides a file? e.g. ./sysroots/lm-sp-gen2/usr/lib/qt5/mkspecs/linux-oe-g++ Jul 15 10:54:54 assuming the file ends up on the target, oe-pkgdata-util can do that Jul 15 11:00:53 Apparently not it seems: $ oe-pkgdata-util find-path usr/lib/qt5/mkspecs/linux-oe-g++ --> ERROR: Unable to find any package producing path usr/lib/qt5/mkspecs/linux-oe-g++ Jul 15 11:01:15 Yet I find it in ./sysroots/laerdal-simpad-gen2/usr/lib/qt5/mkspecs/linux-oe-g++ Jul 15 11:03:18 Point is that my recipe failed, as it could not find this file. I found it in x86_64-linux sysroot, but apparently qmake wasn't looking there. I kept rebuilding with bitbake -k, and now this file also appeared in the target sysroot. Now my recipe could find it, so I presume I lack a DEPENDS statement here. Just figuring out which... Jul 15 11:09:35 Would you need DEPENDS+=qtbase" when you have "inherit qmake5"? Jul 15 11:26:32 I have some 'deeper' questions concerning device tree nodes, gpios and such. Where is a good place to ask/chat? Jul 15 11:31:14 sveinse, I would expect that to happen in the class, but read the class file Jul 15 11:35:38 Is there a way to erase all sysroots, but allow it to use the built packages (so I don't have to rebuild everything all over)? Jul 15 11:35:51 I'd like to check if I got my depends right Jul 15 11:44:47 sveinse: you can run wipe-sysroots Jul 15 11:45:11 the packages will still be available in sstate-cache Jul 15 11:45:40 Ulfalizer: thanks Jul 15 11:46:00 another option is removing tmp/, which contains the sysroots. wipe-sysroots is faster though. Jul 15 11:46:03 np Jul 15 11:47:12 sveinse: make sure you have the build-deps QA check enabled by the way. it's good at finding undeclared dependencies. Jul 15 11:49:03 Ulfalizer: Yes, I got loads on RDEPENDS thanks to it. Is it a general rule that everything going into RDEPENDS also is needed in DEPENDS? Jul 15 11:50:06 sveinse: it's usually a good idea at least, and required for libraries Jul 15 11:51:19 sveinse: i fleshed out http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-DEPENDS a bit recently btw. the second note is semi-related. Jul 15 11:52:49 Yeah, here's one: RDEPENDS contains boost-system boost-filesystem, while adding them to DEPENDS fails with noting provides.... So there are apparently exceptions to the rules Jul 15 11:53:32 sveinse: DEPENDS is a list of recipe names (see the first note in the DEPENDS glossary entry). RDEPENDS is a list of package names. Jul 15 11:54:09 I'll have to admit it takes a while to sift through the code to find what it should read. I can venture a guess at 'boost', but I can't know for sure, right Jul 15 11:54:17 so for boost, some recipe generates the boost-system package, but that recipe is not itself called boost-system Jul 15 11:54:36 not sure off the top of my head either :/ Jul 15 11:54:43 worth a try at least Jul 15 11:55:38 In my debian days, I had a tool that showed the recipe name -> binary name(s) relationship. Is there a similar tool in Yocto? Jul 15 11:58:20 another random question: which of the package systems offers the least overhead on target, esp. wrt disk. ipk? Jul 15 11:58:46 sveinse: can't remember if there's such a tool. one thing you could do is searching for the package name in the build directory. it will be in a subdirectory of a directory corresponding to the recipe name. Jul 15 11:59:05 Ulfalizer: Thanks, thou Jul 15 12:39:17 If I want to define a variable in a receipe, what steps needs to be made for others to access this variable? Jul 15 13:03:32 I'm halfways through my list of populating my DEPENDS list, and it surprisingly passed builds. https://bpaste.net/show/97f73f6ae4dd, I assume that the depends of the depends provides the remaining packages, so it passes. What do I do for the rest? Jul 15 13:20:34 bitbake allows inheritance, right. How do I build on another base-image.bb and tweak a few things? Jul 15 13:53:02 sveinse: don't bother, just copy the image recipe Jul 15 13:53:16 (you'd use the require keyword) Jul 15 13:53:43 the images in oe-core are samples for testing purposes, just copy them for what you want Jul 15 13:54:11 the core-image class has helpers which are likely still useful, so use that still - ie copy core-image-base or something Jul 15 13:56:52 rburton: I see that require require .bbclass, so in principle one should put the worker in the bbclass file and just have a small skeleton in the image.bb Jul 15 13:58:57 we have a subcontractor that has delivered a core-image setup to us, and I'd like to use their image as basis for ours, adding our apps. When I moved their image.bb to image.bbclass, things work out the way I want them to Jul 15 14:02:35 require is "include this file an error if it isn't found", its not classes Jul 15 14:02:49 ie cairo.bb does "require cairo.inc" Jul 15 14:04:08 yeah, sorry, I'm losing myself in the terms: I meant inherit Jul 15 14:04:37 if you want to keep their image pristine and modify it then yeah just require it in your own image and extend it Jul 15 14:04:51 you have have one bb file require another Jul 15 14:05:22 so inherit don't require .bbclass? It can be another .bb file? Jul 15 14:05:37 *inherit* needs classes Jul 15 14:05:48 use include or require for other plain files Jul 15 14:06:00 (include silently does nothing if the file doesn't exist, require errors) Jul 15 14:06:30 ie mesa-gl.bb just does require mesa.bb and then fiddles a few variables Jul 15 14:06:53 but otherwise, inherit and include/require gives exactly the same result, right? Jul 15 14:07:25 not really, inherit is class inclusion, the others are literally take this file and put it here Jul 15 14:07:32 sveinse: one difference is that inherit can handle the same thing being "included" twice Jul 15 14:07:55 rburton: I meant, as seen from the recipe, you get the same kind of variables set and so on Jul 15 14:08:06 sure Jul 15 14:08:26 if your contractor wrote and image and you want to derive from it, just require it in your own image recipe Jul 15 14:08:42 the class will only be processed once, so you don't end up with problems related to things being defined multiple times Jul 15 14:09:33 you can end up with multiple inclusions e.g. if you inherit two classes A and B that both inherit the same class C Jul 15 14:09:58 right Jul 15 14:10:56 other than that, i haven't ran into any situations where thinking of it as a regular include doesn't work Jul 15 14:11:24 *run Jul 15 14:12:22 the search path might be different for 'inherit' and 'include'/'require' i guess... Jul 15 14:13:01 yes, you need the path as well for the latter Jul 15 14:17:47 hrm... there's task overriding too. that has to be class-specific magic. Jul 15 14:21:15 heh, maybe not. looks like the overrides have to come after the 'inherit'. Jul 15 14:31:21 Ulfalizer: EXPORT_FUNCTIONS is class-only. it's just a convenience, though Jul 15 14:32:25 alright Jul 15 14:36:15 There is apparently some subtle difference between the two: If I do "require recipes-bsp/images/lm-core-image.bb", I get something like 4850 tasks that needs building, while if I copy the contents of the lm-core-image.bb into lm-core-image-bbclass, and inherit it from my image, there's only 1900 tasks or so and its done. Jul 15 14:43:31 The subtle difference is that one read IMAGE_INSTALL ?=, the other IMAGE_INSTALL =. The latter pulls in a *lot* more packages Jul 15 14:44:02 and this is why you just write your own image :) Jul 15 14:45:59 Its slightly strange thou: bitbake count up to 1948 tasks. When it hits the last, the number of tasks suddely jump up to 4850 tasks. I thought bitbaked parsed all deps up front Jul 15 14:46:33 setscene vs build Jul 15 14:49:07 we should make sure the setscene progress is finished, and change its description vs the normal runqueue, so you still see the completed setscene progress after it completes Jul 15 14:49:17 then it's clear looking back that it was done, and how many of its tasks were run Jul 15 14:49:23 progress bar, that is Jul 15 14:49:24 sveinse: setscene is when cached task output is fetched from the sstate cache instead of running the task Jul 15 14:49:47 there's a separate setscene pass first where all the setscenes run Jul 15 14:50:20 you can disable the sstate cache by passing --no-setscene btw Jul 15 14:51:01 Ulfalize: more goodies, thanks Jul 15 14:51:48 What I don't understand is why you get lots more activity when IMAGE_INSTALL="..." is chosen vs IMAGE_INSTALL?="..." Jul 15 14:51:57 ?= means "set only if it's not set already" Jul 15 14:52:08 see the bitbake manual, or the yocto project manuals for details Jul 15 14:52:13 sveinse: bitbake -e will show you what the assignment ended up with Jul 15 14:52:47 kergoth: Yeah, but it should not be preset, so if IMAGE_INSTALL is empty, the two variants should turn out the same Jul 15 14:52:53 rburton: I am comparing now Jul 15 14:52:57 sveinse: might be that something else has already set it. in that case the ?= assignment will be skipped, but not the = assignment. Jul 15 14:53:06 sveinse: well apparently it was Jul 15 14:53:09 otherwise there'd be no difference Jul 15 14:53:19 use bitbake -e to see exactly what value it has, and where it was set, as rburton suggested Jul 15 14:53:26 bitbake -e includes the assignment history as well, in the comments above IMAGE_INSTALL=... Jul 15 14:59:27 back to my previous question: What is the procedure for DEPENDS? https://bpaste.net/show/97f73f6ae4dd, I'm half ways through, but compilation is successful, since something apparently is providing the depends I miss from the list Jul 15 15:00:02 I had an iterative approach. Compile, see it stop, add it to the list (after finding its recipe name) Jul 15 15:00:59 There's no clean room sysroot option for yocto? Jul 15 15:02:27 rm -rf tmp, or wipe-sysroot Jul 15 15:02:50 with sstate, wiping tmp really isn't a big deal, it'll reconstruct what's needed Jul 15 15:04:24 kergoth: Yes but no. clean room = bring in /only/ the immediate deps in a sysroot. Its used to ensure that the build deps contain all they need to compile. Yocto seems to be doing an iterative population, like depends of depends, apparently Jul 15 15:04:56 by definition, it'll only being in deps and their deps, but no, it's not possible to make isolated sysroots on a per-recipe basis Jul 15 15:05:22 Otherwise I couldn't compiled with DEPENDS being half the size of RDEPENDS Jul 15 15:05:28 that's a feature we've wanted for some time to avoid automatically detected deps causing non-deterministic builds due to build order changing the sysroot contents Jul 15 15:05:44 yes, I see the need for it :D Jul 15 15:05:47 first of all, if you bitbake yourrecipe:do_compile, rather than bitbake yourrecipe, the rdeps won't be built at all Jul 15 15:05:53 the rdeps are built by default, but only for packaging Jul 15 15:06:09 ah, good. Let me take that approach. thanks Jul 15 15:06:43 should make it slightly more sane, since there's no random builds of rdeps occurring throughout. still not completely isoalted, since it's both deps and deps of deps, but it's as close as we can get at this time Jul 15 15:08:55 kergoth: is 'bitbake -c task foo' the same as 'bitbake foo:do_task'? Jul 15 15:09:40 IMHO, having fully isolated builds in all recipes, would take a ton of resources. We do that for a custom build system we run today, and it's honestly a pain for complete rebuilds. It's great as a tool to check/develop recipes, but I don't feel the need for it on a system build. My 2 cents... Jul 15 15:14:44 Ulfalize: yeah, for that particular example they're identical. the former will affect all specified targets, of course, and the latter syntax can override -c. i.e. bitbake -c foo bar baz:do_bar -> runs bar:do_foo & baz:do_bar Jul 15 15:17:56 The images I'm building come with a root passwd of root which makes -f testimage unhappy - I've tried adding debug_features to IMAGE_FEATURES without any improvement is there something else I need to fiddle with? Jul 15 15:20:27 'root' isn't a standard default root password for oe/yocto images, so it's something specific to your setup doing it Jul 15 15:26:13 just looking for an EXTRA_USER_PARAMS setting Jul 15 15:27:51 kergoth: ok Jul 15 15:40:22 kergoth: found it - thank you! Jul 15 17:41:40 * ulf` is thining about getting the new Costco Visa card Jul 15 17:41:47 4% cash back on gas and 3% on travel I believe Jul 15 17:41:49 hmmm Jul 15 18:39:57 guys, I'm particularry interested in this patch http://lists.openembedded.org/pipermail/openembedded-core/2016-July/123947.html Jul 15 18:40:03 when could I expect this to be merged? Jul 15 19:02:59 Xz: it was posted today isnt it Jul 15 19:03:25 Xz: look for it on ross/mutt branch on poky-contrib tree Jul 15 19:03:41 and then it can be any number of days after that depending on test results Jul 15 19:04:09 ulf`: yes costo card is great, I have been using for ages Jul 15 19:05:22 khem: alright, so by default it doesn't go to master branch? Jul 15 19:14:15 Xz: it does but after some testing Jul 15 19:20:27 patches have to get reviewed, tested, and pass the autobuilder Jul 15 19:20:38 and then a group of patches fails so we need to figure out why it breaks Jul 15 19:22:25 yesterday all the SDK images failed to build without any messages, which after a 12 hour bisect run was blamed on piglit, which make me remember that there was a size limit for hddimg files which was likely happening as piglit is giant now, so after verifying that was the case and fixing bitbake's broken shell->cooker logging (which was why there were not any messages) and removing piglit the autobuilder is unblocked again Jul 15 19:22:49 so thats babysitting a 12 hour bisect and four hours of work due to a single package upgrade Jul 15 19:23:02 (and a regression that nobody noticed for about three weeks) Jul 15 19:23:12 so yeah, patches don't go straight to master :) Jul 15 19:23:34 its in my mut, and i do notice that the buildhistory-diff from it is about two pages Jul 15 19:24:57 (mut stands for master-under-test) Jul 15 19:26:12 rburton: I would expect you to be vocal on mailing list if you are doing all this hard work Jul 15 19:26:21 so folks know if some patches are causing gripes Jul 15 19:27:13 the piglit one was the standard small thing with giant consequences Jul 15 19:27:21 rburton: I feel so happy now it wasn't me to submit that piglit change Jul 15 19:27:33 rburton: by the way piglit sounds like some pokemon name Jul 15 19:27:54 the problem is that the AB tests such a large combination its easy to not hit the problem in testing Jul 15 19:28:10 now i'm wondering why some builders are having rpm explode with lock failures during rootfs Jul 15 19:28:21 rburton: this will also create awareness in community that they have to do better to help speed absorption, test your stuff before submitting Jul 15 19:28:55 rburton: thats nice to have a wider coverage, no doubt Jul 15 19:29:18 error: db3cget:../../rpm-5.4.15/rpmdb/db3.c:1514: dbcursor->get(-30972): BDB0088 DB_SECONDARY_BAD: Secondary index inconsistent with primary Jul 15 19:29:27 * rburton fires ICBMs at rpm Jul 15 19:30:51 khem: highlight of today was busybox mailing list wondering how they can get their server back online Jul 15 19:30:58 as nobody there can remember the sudo password Jul 15 22:00:11 ulf: interesting, in Canada costco has partnered with mastercard, so the costco cards here are mastercards, not visas Jul 15 22:00:28 ulf: they used to be with (ironically) american express, but changed about 2 years ago to MC Jul 15 22:01:06 ulf`: ^ (oops, forgot the backtick) Jul 15 22:02:32 ulf`: we've been using it for years too, the only unfortunately part is that their gas stations only sell gasoline, not diesel as well, so only some of our vehicles can get cheap gas :-) Jul 15 22:32:38 tlwoerner: mastercard transactions go through visa too Jul 15 22:32:44 they dont see them as competition Jul 15 22:33:24 rburton: heh thats funny Jul 15 22:34:49 khem: latest wayland upgrade breaks on musl if you fancy sending a quick fix, i'm off to bed. see nightly-musl on the AB Jul 15 22:37:51 hmm Jul 15 22:41:35 rburton: s/uint/unsigned int/ Jul 15 22:56:47 tlwoerner: You mean the Amex version of the deal Jul 15 22:57:22 tlwoerner: Now the card is Visan and I think the cashback rate went up by a point for purchases Jul 15 23:07:51 sveinse: oe-pkgutil lookup-recipe $packagename gives you the recipe name for a package Jul 15 23:18:03 neverpanic: it should be oe-pkgdata-util Jul 15 23:18:30 oh yeah, sorry, not at the machine to check this atm Jul 15 23:20:22 ulf`: what i'm saying is that in canada the costco card used to be amex but they switched to MC about 2 years ago (or so). i think it's interesting that the us and canadian costcos made their own agreements, and they both chose differently (can:amex->mc, us:amex->visa) Jul 15 23:33:24 tlwoerner: as i said visa and mc are same backend **** ENDING LOGGING AT Sat Jul 16 02:59:58 2016