**** BEGIN LOGGING AT Thu Aug 07 02:59:59 2014 Aug 07 04:06:41 I have yacto installed on imx6qsabrelite board. But I do not have rpm-build. How can I get it installed Aug 07 08:43:52 Hello, I have a problem with a dependency: libgles-omap3 (from meta-ti) provides libgles2 (it's in its "control" file), qmake (from meta-qt5) is configured with it (I can see it in log.d_configure) but there is a problem during the do_package Aug 07 08:44:04 "NOTE: Couldn't find shared library provider for libGLESv2.so, used by files: [...]" Aug 07 08:44:44 what can I try? Aug 07 08:50:35 morning all Aug 07 08:57:05 good morning Is there a variable in bitbake that contains the size of the root patition of the image that is build? Aug 07 09:02:11 wfailla1: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_SIZE Aug 07 09:17:12 bluelightning: thx ;) Aug 07 09:36:19 hi, what is the general practice of testing the software on board with the help of Yocto? Just having foo-test packages generated by the "main" recipe, install and run them or something else? Aug 07 09:47:02 how can the python binary be so small when it is 2.8 MB on my desktop? 16K ./tmp/work/armv5te-foo-linux-gnueabi/python/2.7.3-r0.3/image/usr/bin/python2.7 Aug 07 10:59:50 lpapp: for software testing in yocto, use ptests : https://wiki.yoctoproject.org/wiki/Ptest Aug 07 11:11:19 maxin: the problem with ptest is that I would not like to run every test in one job ... because that would take me ages. Aug 07 11:12:09 if I am developing only tool "foo", I would rather not wait for all the tools to be tested before I get some notification whether I broke something, therefore ptest is not suitable for me from the look of it, I am afraid. Aug 07 11:13:36 lpapp: you can run the test for just package "foo" by going to " /usr/lib/foo/ptest" Aug 07 11:14:00 sure, but then what is the merit of the added complexity? Aug 07 11:14:08 I can also just as well do ./mytestscript. Aug 07 11:16:54 lpapp: yes. you can do that as well. One design goal of ptest is to create a standardized way to run tests and get properly formatted test results. Aug 07 11:17:35 maxin: my test suite already provides proper failure reporting since it oughta work outside Yocto, too. Aug 07 11:19:06 (I would rather not make the testing Yocto specific so that it could not be done outside of it, then) Aug 07 11:19:27 portability is a good trait. Aug 07 11:21:47 lpapp: This is a very good read: http://daniel.haxx.se/blog/2012/08/31/ptest-because-make-test-is-insufficient/ Aug 07 11:23:53 maxin: we do not use make test. Aug 07 11:26:10 lpapp: you can use any commands to run the tests. It really doesn't matter. ptest just demands "automake test output syntax" .. Aug 07 11:27:25 well, that is the thing, I do not like automate either :-) Aug 07 11:27:31 automake* Aug 07 11:28:06 I guess what I am really looking for is this: what is the generic way of creating test packages that I have control over and does not get too Yocto specific, like ptest? Aug 07 11:28:18 lpapp: it is your choice. Again, you don't need automake to create the output syntax :) Aug 07 11:28:22 currently, I am doing foo-test, install it, and then run it. It does everything I need. Aug 07 11:28:36 lpapp: good Aug 07 11:28:52 but I was wondering if this is the generic way since software testing is a generic concept (even goes beyond Yocto, yes). Aug 07 11:29:46 currently, I cannot see what additional gain ptest would do over foo-ptest. Aug 07 11:29:55 lpapp: you are free to implement and propose to the community.. Aug 07 11:30:26 I cannot even understand how failure reporting is with ptest to be honest. It is up to the test suite used in pretty much all cases that I have come across. Aug 07 11:30:54 it is a crucial feature of any test suite... so why would ptest re-do it? Aug 07 11:32:05 a bit more thought onto the fire: automake is not even the leading build system, it is ancient and the most disliked by people that I have come across out of the available options. Aug 07 11:32:28 lpapp: In our case, it helps in analyzing the test output in a structured way (it is not perfect, but does what it says) Aug 07 11:34:31 maxin: let us say, there is one test script, running 5000-6000 test cases, and there is 100 scripts like that. What you will get from ptest is only 100 equal reports, but 500-600K different test runs. Aug 07 11:35:00 because the test script will use its own test suite for error reporting. Aug 07 11:35:36 is ptest's goal to "standardize" that 100 "lines" in this case? Aug 07 11:36:07 lpapp: can you please share your example outputs or send patches to fix those problems ? Aug 07 11:36:37 I do not see any problem... ptest seems some which I cannot see.. Aug 07 11:36:45 seems to see* Aug 07 11:36:52 I am trying to understand what it is trying to achieve. Aug 07 11:37:35 lpapp: please try the link that I shared above. I think it explains fairly okish.. Aug 07 11:38:16 I have read both, yet I do not understand the goal it is trying to achieve, hence asking. Aug 07 11:47:03 my only assumption is this: 12:32 < lpapp> is ptest's goal to "standardize" that 100 "lines" in this case? Aug 07 11:47:16 just a short one: where are the /etc defaults coming from, e.g. /etc/network/interfaces for example? Aug 07 11:47:59 I have doubts on its implementation side, too: I can only turn all ptest packages on or nothing with the distro feature? I would like to be able to skip the testing of meta/ and only test stuff in my meta-foo/ Aug 07 11:52:04 when I wish to test one small util, I would rather skip building of every single ptest package since that would be waste of time and resource (and money). Aug 07 11:52:23 so is it possible to build ptest for only one particular package? Aug 07 11:53:12 LetoThe2nd: init-ifupdown package Aug 07 11:55:43 maxin: thanks Aug 07 11:55:44 lpapp: It is not possible to build ptest for only one package. that is not supported at this time. Aug 07 11:57:11 maxin: is there a ticket for this open? Aug 07 11:58:30 cannot see any here: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=ptest&list_id=262153 Aug 07 11:59:11 lpapp: however, if you really want to test that package alone, remove "inherit ptest" from other packages. Aug 07 11:59:53 maxin: that would yield the modification of many vanilla recipes. Aug 07 12:00:09 will not take that path until it gets fixed in Yocto. I will remain a non-ptest user until that point. Aug 07 12:00:31 but I am confused why these things are not reported to QA/Testing as opposed to oe-core, etc. Aug 07 12:00:40 I guess the lines can seem blurry for a newbie ... Aug 07 12:02:54 lpapp: that is not a pressing problem since you can run the tests for a particular package in the image, if you want to.. Aug 07 12:04:06 it is not only pressing, but blocker for me. Aug 07 12:04:21 1) I do not want to waste resource, time and money with waiting for other needless builds. Aug 07 12:04:27 2) I do not want to bloat the images with other things, either. Aug 07 12:04:29 lpapp: care to explain how ? Aug 07 12:04:35 already did ^ Aug 07 12:04:50 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6615 Aug 07 12:04:51 Bug 6615: normal, Undecided, ---, saul.wold, NEW , Make it possible to generate a ptest package for only one package or several of them Aug 07 12:13:27 maxin: hm, whats the most elegant way to override the interfaces then? i'm thinking of init-ifupdown in my layer, and then adding it to SRC_URI Aug 07 12:14:46 i mean a bbappend in my layer Aug 07 12:15:38 LetoThe2nd: yes, I have used the same way.. Aug 07 12:15:42 or do i need a do_install_append_mymachine = {blablabla} ? Aug 07 12:16:53 because a simple SRC_URI += "file://interfaces" did not seem to pick it up Aug 07 12:16:53 LetoThe2nd: do_install_append() { Aug 07 12:16:54 case "${MACHINE}" in "mymachine" Aug 07 12:16:54 install -m 0644 ${WORKDIR}/interfaces ${D}${sysconfdir}/network/interfaces;; Aug 07 12:16:54 *);; Aug 07 12:16:54 esac Aug 07 12:17:43 maxin: ah thanks! Aug 07 12:17:46 LetoThe2nd: you need FILESEXTRAPATHS, not SRC_URI Aug 07 12:18:15 maxin: mayhaps ... it is not a blocker if I do not clean everything up in my jenkins job, so the ptest packages do not get rebuilt, or something, yet I would not populate any image or so... just regular scp. Aug 07 12:18:29 JaMa: ok now i'Ve been confused successfully Aug 07 12:18:35 (although I would rather keep a jenkins job clear) Aug 07 12:18:37 clean* Aug 07 12:19:08 LetoThe2nd: JaMa: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" in bbappend ? Aug 07 12:19:57 yeah, that is how it usually goes. Aug 07 12:20:07 maxin: correct, just using BPN instead of PN is good habit Aug 07 12:20:33 then put your interfaces file in BPN/mymachine/interfaces Aug 07 12:23:08 ok, let me give it a try Aug 07 12:23:42 so what happens when I type "bitbake core-image-minimal" with ptest on? Will all the ptest packages be built? Aug 07 12:23:47 (I will try it now) Aug 07 12:23:54 JaMa: thanks ! Aug 07 12:25:06 lpapp: no. ptests for packages which are part of the core-image-minimal will be included. Aug 07 12:25:20 yes, that is what I meant. That is sad. Aug 07 12:25:35 I thought I could circumvent it this way, but apparently no joy. Aug 07 12:25:47 hm, does not seem to pick it up Aug 07 12:26:20 i've got recipes-core/init-ifupdown/init-ifupdown-1.0/mymachine/interfaces in my layer. Aug 07 12:26:51 and recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend in my layer justcontains the above give line with BPN Aug 07 12:26:52 and what happens if I do not add ptest to DISTRO_FEATURES, but I inherit that class in a recipe? core-image-minimal will not build ptests, but if I do an explicit foo-ptest? Aug 07 12:27:03 (is that even possible? If not, I think that would be the nice way of improving the system) Aug 07 12:27:19 LetoThe2nd: init-ifupdown-1. != BPN Aug 07 12:28:13 init-ifupdown it would be? Aug 07 12:28:18 y Aug 07 12:32:05 ok.. seems like now something fishy is going on... second Aug 07 12:34:36 ERROR: Function failed: license_create_manifest Aug 07 12:35:27 ls: cannot access /home/sepp/Projekte/mymachine/build-updater/tmp/sysroots/mymachine/pkgdata/runtime-reverse/init-ifupdown: No such file or directory Aug 07 12:35:42 do i have to place a new license file in the directory too? Aug 07 12:40:52 hm. BPN->BP and renaming the directory to init-ifupdown-1.0 did the trick. probably because the structure is the same in the overridden recipe. is that possible? Aug 07 12:42:34 I don't think so Aug 07 12:44:00 strange then. Aug 07 13:29:14 is there a good example for a license file check etc. in a recipe that only installs some files/scripts? Aug 07 13:29:46 like placing it in BPN? or where is it supposed to go then? Aug 07 13:31:51 ah nvm, sorry for the noise. initscripts serves fine. Aug 07 13:50:10 for a trivial install, install -m 0755 ${WORKDIR}/helloworld.sh ${D}${bindir}/helloworld.sh fails because the file is not in the usr/bin directory in the workdir. is there some particular reason behind i can't install the script directly to the bindir? Aug 07 13:51:19 hey, where can I find the load address for the kernel (zImage) Aug 07 13:51:26 ? Aug 07 13:55:35 Hello, I got the meta-atmel from github Aug 07 13:55:50 and want to add barebox in stead of uboot Aug 07 13:56:17 So I added barebox to meta-bsp etc... Aug 07 13:56:33 however, when bitbake, it complains for a missing defconfig Aug 07 13:56:46 where do I get this one? (or how does it get involved) Aug 07 13:58:21 LetoThe2nd: I can't see anything that would be a problem there Aug 07 13:58:46 LetoThe2nd: the source directory shouldn't be important to where it ends up in ${D} Aug 07 13:59:10 LetoThe2nd: did you ensure ${D}${bindir} exists first using install -d ? Aug 07 14:01:21 bluelightning: i admit i take the existence of /usr/bin on the target as granted. Aug 07 14:01:48 LetoThe2nd: it's not so much about the target, but about ${D}... it's empty by default Aug 07 14:02:11 bluelightning: ah. then i understood it the wrong way. Aug 07 14:02:42 it only contains the files installed by the current recipe alone, so unless you create that directory there it won't already exist Aug 07 14:03:17 bluelightning: yeah, i think i got it. my mind was just set onto a wrong thinking model Aug 07 14:09:13 bluelightning: thanks, everythings working now. Aug 07 14:19:04 np Aug 07 14:27:12 bluelightning: hey! Aug 07 14:27:26 hey Marex__, how are you? Aug 07 14:27:41 bluelightning: great, thanks for asking ! :) Aug 07 14:27:47 bluelightning: hope you're great as well ;-) Aug 07 14:27:53 Marex__: I am indeed :) Aug 07 14:28:03 I'm about to spam the oe-core ML with some patches :) Aug 07 14:28:57 Marex__: great, spam away :) Aug 07 14:32:03 bluelightning: I want to add the U-Boot fitImage support into Yocto Aug 07 14:32:22 bluelightning: it's nice for industrial stuff, since it contains all those checksums and stuff Aug 07 14:33:45 moin Aug 07 14:34:49 mr_science: good morning Aug 07 14:38:44 ERROR: Fetcher failure: Unable to find file file://defconfig anywhere. Aug 07 14:43:09 wv: you need to add it in your recipes area unless you are using a standard defconfig Aug 07 14:46:06 khem, it may be the standard at91sam9260ek_defconfig (at91sam9260ek_defconfig) but I'm not quiet sure where this fits in or where I define thisµ Aug 07 15:23:19 bluelightning: it's all there, now you all can yell at me and scream in horror :) Aug 07 15:23:52 ah no, I need to subscribe, so all my stuff was rejected automatically ... that's nice Aug 07 15:27:11 ok, better Aug 07 16:23:58 can anyone please answer my question in the morning: why is the python binary so small compared to my desktop one? I mean, there are orders of magnitude. Aug 07 16:38:52 meh Aug 07 16:39:06 lpapp: probably because the device one links to libpythonX.Y.so and your desktop one has that library statically linked. Aug 07 16:39:09 u-boot/master doesn't build with meta-toolchain-qte from yocto 1.6 Aug 07 16:39:24 the toolchain is missing a python subprocess module, I guess it's time for a patch Aug 07 16:40:38 gabrbedd: does not seem so, ldd -r /usr/bin/python2.7 | cutepaste Aug 07 16:40:38 http://pastebin.kde.org/pvzihkgxz Aug 07 16:41:31 lpapp: ok Aug 07 16:43:56 lpapp: maybe the binary is stripped/unstripped ? :b Aug 07 16:44:10 maybe there are debug symbols in one of them ? Aug 07 16:44:12 who knows ... Aug 07 16:44:37 Marex__: both are stripped of course. Aug 07 16:46:37 * darknighte -current gets up to stretch legs Aug 07 16:49:11 lpapp: of course! Aug 07 17:02:50 back... Aug 07 17:20:05 What would be the best way to customize some files of a package/recipe? I want for example alter the sudoers file of the sudo package (allow all users in sudo group to use sudo). Aug 07 17:22:08 create a layer, add a bbappend to that layer, and in there append do_install to either directly make your changes, or install your own sudoers which you add to SRC_URI Aug 07 17:23:32 the details often depend on where the file originates; i.e. is it directly in SRC_URI or not and is it separately installed in do_install or did it come from upstream and get installed via "make install" Aug 07 17:24:31 FWIW I'd like to have a tool that allows you to create bbappends to do this automatically: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6447 Aug 07 17:24:33 Bug 6447: enhancement, Medium, 1.7, paul.eggleton, NEW , Add ability to find a target file and create a bbappend to replace it Aug 07 17:25:32 you'd think we could create a sort of config file sysroot and then have a package hook which replaces any file in ${D} with the one from the config file sysroot if it exists there, or something Aug 07 17:30:04 kergoth: that's an interesting way of handling it... hmmm Aug 07 17:31:33 is there a tutorial/documentation/example of a bbappend file where some files get replaced? Aug 07 17:32:46 of course, that method would only lte you override entire files rather than modify them/patch them, but thatd be a decent comprimise since itd mainly be provided for users.. distros/etc would likely still just append and tweak as they like Aug 07 17:33:16 auke-: it does not need a tutorial, you just put the file into the subfolder beside the .bbappend Aug 07 17:34:30 for instance this is how we replaced fstab: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" Aug 07 17:34:37 in the .bbappend ^ Aug 07 17:35:01 and then meta-foo/recipes-core/base-files/base-files/fstab Aug 07 17:37:46 okay, i will try that. thanks **** ENDING LOGGING AT Fri Aug 08 02:59:59 2014