**** BEGIN LOGGING AT Thu May 21 02:59:58 2015 May 21 07:08:23 good morning May 21 07:34:46 hi all! May 21 07:35:46 is there a way to build Qt 5.4 for edison? May 21 08:12:21 morning all May 21 08:18:49 good morning May 21 08:19:07 what is the recommended way to extend the PATH for a particular with /sbin? May 21 08:19:18 via the rootfs post command variable or something else? May 21 08:29:46 lpapp: hi May 21 08:29:55 lpapp: extend it for what context? May 21 08:33:38 bluelightning: PATH=/sbin:$PATH May 21 08:33:42 for user "joe" May 21 08:33:52 because we run our services under user "foo/joe" May 21 08:34:03 and there are binaries in /sbin that should be found without full path. May 21 08:38:23 I'm not sure but I guess you'd do that through /etc/profile May 21 08:38:36 more of a general Linux question than specific to our system May 21 08:39:39 well, you have to do this through the buildsystem May 21 08:43:37 bluelightning: I have an annoying but not a big issue; so sometimes when I do bitbake after editing its recipe, it sometimes forgets to recompile the whole thing even though I do bitbake -c clean. May 21 08:43:43 any input? May 21 08:44:25 chankit: have you also tried cleanall/cleansstate? May 21 08:45:29 lpapp: eh no. I thought the only difference between cleanall and clean is cleanall deletes the downloaded source files? May 21 08:45:49 not as far as I know. May 21 08:47:03 chankit: what kind of change were you making? May 21 08:48:38 sometimes I edit do_compile or do_configure methods in my recipes. However, getting back to the issue, I can do bitbake -c compile and it does compile. But it doesn't install though so I have to run bitbake -c install as well May 21 08:50:12 hi everyone, I would like to add a capabilty to a binary (cap_sys_time+ep), is there a way to do it into a recipe? (I was thinking about add setcap cap_sys_time+ep ${D}/home/foo/foo in do_install but I need to be root) any idea? May 21 08:50:40 bluelightning: the original symptom is that my application can call a binary in /sbin with dylan, but not with daisy May 21 08:51:05 bluelightning: the way that I find the executable is through a C function "exec_exists" which just goes through the PATH variable after obtaining it with getenv(). May 21 08:51:12 I do not know why that would break with daisy... May 21 08:51:30 lpapp: I don't immediately know how that would have changed, but /etc/profile or the user's .profile is probably how PATH gets set May 21 08:52:02 bluelightning: https://paste.kde.org/pubvbbjqy May 21 08:52:06 bluelightning: this is the simple C function May 21 08:52:17 I am just showing to point that out there is nothing that can break in this code May 21 08:52:38 line 20-25 is my workaround, but I still would like to understand why it can break with daisy. May 21 08:52:50 fwiw, su - foo and then echo $PATH does not contain /sbin in either case, so .... May 21 09:02:15 that buildbot project do look intresting..no fancy stuff, just jinja and python May 21 09:14:14 Hi ! May 21 09:14:25 I'm trying to apply config fragments to my kernel conf, but it seems to be never set in the final .config :/ May 21 09:14:50 I created a .bb file for my kernel (based on linux-yocto) and tried to add the cfg fragment and/or a .scc file containing "kconf hardware my.cfg" to SRC_URI without success May 21 09:15:10 QA checks reports this as a warning but I have no clues how to fix it May 21 09:29:47 CromFr: if you don't get an answer here I'd suggest mailing the mailing list and CCing Bruce Ashfield **** BEGIN LOGGING AT Thu May 21 09:35:43 2015 May 21 09:45:30 hi. i'm not sure why i keep having problem this: i've built a custom dist and i'm using meta-raspberrypi (currently) as bsp. but how do i set which kernel to use? May 21 09:47:07 i have an image file in meta-mydistro/recipes-core/images and i've set PREFERRED_VERSION_linux-raspberrypi ?= "3.18%" in it. but 3.16 is used instead. May 21 09:48:58 ionte: if you use bitbake -e | less to look at the history of the variable value can you see if the value you are setting is being overridden? May 21 09:51:00 bluelightning: thanks, was not aware of "-e"! May 21 09:52:26 bluelightning: PREFERRED_VERSION_linux-raspberrypi is only set once in the output, by rpi-default-versions.inc in meta-raspberrypi, and it's set to 3.16 May 21 09:54:36 bluelightning: if the value was set in one file, and then changed by another, both values should appear in the -e output right? May 21 09:55:29 ionte: have you tried PREFERRED_VERSION_linux-raspberrypi = "3.18%" (instead of ?=) May 21 09:56:52 CromFr: yes, i've tried both = an ?= May 21 09:58:37 ionte: Maybe PREFERRED_VERSION_linux-raspberrypi_machinename = "3.18%" ? May 21 09:59:08 so, i have an image file ("griffin-dev-image.bb") which "require griffin-base.inc", and the PREFERRED statement is in griffin-base.inc. if i change griffin-dev-image, for example add to IMAGE_INSTALL, those changes are used. so i'm quite sure the code in the image file is executed May 21 10:01:06 CromFr: did not help May 21 10:03:12 ionte: I've just re-read what you said and I now noticed you are setting the value in an image recipe - that will not work I am afraid May 21 10:03:33 ionte: PREFERRED_* need to be set at the configuration level May 21 10:05:41 bluelightning: hmmm... ok, what do you mean by "configuration level"? May 21 10:06:27 conf/local.conf? May 21 10:08:28 ionte: local.conf or custom distro/machine config, basically May 21 10:10:26 Hey, I have got a problem with a kernel bbappend. Could anyone have a look and tell me what I have done wrong? :( https://gist.github.com/zwerch/5a7e28408916fd0f3272 May 21 10:10:27 bluelightning: ok! for other hardware i've used previously i had a custom machine config, but not for raspberry pi... May 21 10:11:13 bluelightning: success! thanks! May 21 10:17:11 zwerch: er, so it looks like you're putting symlinks to the modules in /etc/modprobe.d - is that really the right thing to do? AFAIK what's supposed to go in there is conf files specifying options for loaded modules May 21 10:18:32 zwerch: if it is simply module autoloading you are after, we have a mechanism for that FYI - KERNEL_MODULE_AUTOLOAD += "mymodule1 mymodule2 ..." May 21 10:19:36 zwerch: that's for dizzy (1.7) and beyond; for older versions use module_autoload_modulename = "modulename" May 21 10:19:39 bluelightning: Oh :O May 21 10:19:39 I have started working with Yocto not that long ago and we're all new to it. I was just told that they would be loading if I link them there. I didn't know you can approach this otherwise. So thanks for that. May 21 10:19:39 Where do I put that? May 21 10:20:24 zwerch: that can go in the kernel recipe, or in your configuration (custom machine config, distro config or local.conf) such that it will be seen by the kernel recipe May 21 10:20:48 ionte: great, np May 21 10:20:56 bluelightning: Okay, so I could do it in my bbappend? May 21 10:21:01 zwerch: yes May 21 10:22:06 zwerch: it's not really applicable this time, but just in case you need to know later, FYI there's a bunch of info on solving QA issues here: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-qa-checks May 21 10:24:46 bluelightning: Thanks, I found that already, and I already solved this kind of error once, but this time none of my earlier approaches worked. May 21 10:24:46 So, thanks for your help and time. I really appreciate it! :) May 21 10:24:58 zwerch: no problem May 21 10:31:05 otavio: https://autobuilder.yoctoproject.org/main/builders/nightly-fsl-arm-lsb/builds/312/steps/BuildImages/logs/stdio <— we're removing gst 0.10 from oe-core, can you update the bbappends? May 21 11:02:25 otavio: do you approve of the fitimage series? May 21 11:04:20 hi , I'm having problems with I2C controller on my custom ARM SoC board May 21 11:04:34 can anyone help me out ? May 21 11:07:14 what problems? Are they related to Yocto? May 21 11:11:22 ummm.. not sure specifically, I've enabled the driver from the menuconfig during the kernel build process, but when i use i2c tools, it fails with timeout error May 21 11:28:04 sighack: as usual - try to isolate the problem. is it hw or sw? did you check with a scope, et.c.ppp. May 21 11:29:11 well we have got it designed from a 3rd party and they say that they have tested it using bare-metal application .. so i think the hardware part is fine. May 21 11:29:30 I'm not sure whether it is a driver issue or could be problem with the dtb file May 21 11:29:34 is it possible that when creating a bitbake recipe for a kernel module it forgets to pass on the KERNEL_SRC variable? May 21 11:29:44 in the module_install step May 21 11:29:58 sighack: "they say" and "i think" are not really good starting points May 21 11:30:29 sighack: with a scope you could at least verify if something actaully reaches the lines, or not. May 21 11:30:42 jaeckel: not sure what you mean, how could I check that? May 21 11:30:43 sighack: if there's nothing on the line, a sw is very probably. May 21 11:31:14 sighack: I started from May 21 11:31:19 http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules May 21 11:32:08 LetoThe2nd: ohk, but the schematic is not open, and the board lines are unapproachable coz of connector placements :| May 21 11:33:07 sighack: well so what do you expect from us then? May 21 11:33:10 sighack: very unlikely to have an issue with KERNEL_SRC May 21 11:33:29 sighack: does your kernel work fine without Yocto? That is the first thing that I would check. May 21 11:33:38 to see whether this is any Yocto related. May 21 11:34:03 sighack: if you can't even check whats going on in your hw, debugging a hw interconnect is rather hard. May 21 11:34:12 sighack: ah sorry, my question was not related to you May 21 11:34:13 jaeckel: im not creating my own modules, I'm simply enabling the related driver thru the menuconfig. May 21 11:34:24 (if not, you better visit #kernelnewbies) May 21 11:34:35 sighack: so maybe you should pay your 3rd party for some more assistance in getting you started. May 21 11:34:58 lpapp: well , kernels are working fine. As the board is able to boot up and all May 21 11:35:14 lpapp: you're mixig up the questions of jaeckel and sighack May 21 11:35:20 lpapp: yes, thanks for the pointer, i think #kernelnewbies is one place is should visit May 21 11:35:50 LetoThe2nd: I am not. May 21 11:36:08 sighack: so if you use your kernel built outside of Yocto, it all works? May 21 11:36:18 LetoThe2nd: haha maybe i will bug them too. Any device tree related pointers ? May 21 11:36:20 lpapp: well then, go ahead. i'm out. May 21 11:36:47 sighack: I do not think you need to check the hardware at this point. May 21 11:36:56 sighack: first check the software trivia May 21 11:37:06 sighack: check any related device tree example for a good known board that uses the same or a aclosely related soc May 21 11:37:18 LetoThe2nd: i will try and confirm the working with the bare-metal code atleast. That should help me emilinate hw problem. May 21 11:37:29 sighack: but if you don't know the schematics, you can't verify pinmuxing, and you are basically... well, on your own. May 21 11:37:53 * LetoThe2nd vanishes in a poof of thin air May 21 11:38:21 sighack: so far you have not showed any evidence why it may be tangentially related to Yocto, so why did you come here? :) May 21 11:38:24 LetoThe2nd: yeah, I'm basing my dtb dev on a close version itself. But there are quite a few changes in design so i think im stuck there, May 21 11:38:40 what made you think this is a Yocto problem? Is there something that you have not shared? May 21 11:39:53 lpapp: umm.. to be honest I'm was not sure where to go, since I'm using yocto to build the system I thought it would be a good start. No offence intended. May 21 11:40:14 right, so the way I debug these issues in such cases: build the kernel outside of Yocto. May 21 11:40:17 and see if it works. May 21 11:40:28 if it does not, I can tell that to the Yocto developers. May 21 11:40:36 in what scenarios did it work. May 21 11:40:51 then if it does not work outside of Yocto and I have no clue, I go to #kernelnewbies. May 21 11:41:07 lpapp: so u mean get the kernel source code seperately and compile it ? May 21 11:41:18 yes, it is just a make command after all once you configure it. May 21 11:41:34 obviously, you need to use the right toolchain, but for that, you can use the one from Yocto. May 21 11:41:48 (or from any other suppliers, like Mentor Graphics, etc) May 21 11:43:12 at this point, I would trust your hardware supplier and try to find the failure in software. May 21 11:43:24 thanks for the help guys! May 21 11:43:39 and if the software turns out to be good, then I would go down deeper as that investigation may require more time. May 21 11:44:09 (but these are just my practices for the last couple of years with the kernel; not necessarily good or bad) May 21 12:26:05 gm May 21 12:26:52 gm May 21 12:30:36 likewise :) May 21 12:32:06 yes? thanks :) May 21 13:15:19 Hello, I have a problem with an autotools / libtool library to compile on yocto. During the configuration the variable includedir is set to /usr/include. But the real one must use the path .../poky/builds/ip-spt-am335x/tmp/sysroots/sdnam335xeval May 21 13:15:36 bluelightning: we did not continue the discussion about PATH ... May 21 13:16:06 ROOTFS_POSTPROCESS_COMMAND or something else? May 21 13:16:07 The makefile use $(includedir)/path_to_lib to set the dependency May 21 13:17:22 mad_jeff: I believe that is the correct value of includedir for a target recipe... the appropriate sysroot path is supposed to be prepended to that where needed May 21 13:17:57 mad_jeff: if includedir is changed to point to the sysroot as well then you'll get that path bleeding into the target environment as well which is not what you want May 21 13:19:50 lpapp: "git grep -w PATH" shows me that it is indeed /etc/profile setting PATH (in meta/recipes-core/base-files/base-files/profile) May 21 13:20:05 lpapp: so bbappend base-files and replace that file with your preferred contents May 21 13:20:44 rburton: any specific advice for mad_jeff ^ ? May 21 13:21:21 bluelightning: that is global. May 21 13:21:40 lpapp: it is yes May 21 13:22:00 bluelightning: I want local, that is why I thought ~/.profile, but my point is how to do it right. May 21 13:22:10 lpapp: do you care to not have sbin in some users PATH values? May 21 13:22:17 yes May 21 13:22:34 you know, the usual minimal principle... give it to the user who needs it. May 21 13:22:41 in this case the user under which the system services will be running. May 21 13:23:32 lpapp: alright, well, we have no mechanism that I know of to specifically set up .profile for individual users May 21 13:24:00 so what would you suggest, ROOTFS_ ... ? May 21 13:24:28 bluelightning: Ok I understand the principe, but the compile doesn't found dependency, and if I change the makefile to use the fullpath instead $(includedir)/lib this is working... Any idea where the problem can from ? May 21 13:25:37 lpapp: I don't have any alternative suggestion if that's what you're asking May 21 13:25:59 bluelightning: well, I could also create a recipe for installing a file into a specific location May 21 13:26:04 but that is even nastier IMHO :-) May 21 13:26:37 lpapp: AFAIK installing things into home directories via recipes is discouraged May 21 13:27:27 lpapp: you might consider adding logic to the (yes, global) profile file that could determine in a more appropriate way for your situation whether the additional items should be added to PATH May 21 13:27:52 lpapp: e.g. looking whether the user is in the wheel group would be one way, assuming you had such a group May 21 13:28:01 yeah May 21 13:30:32 mad_jeff: I'm certainly not an autoconf expert by any means but it sounds like what you should have is an option to pass that include path into the configure script; you could patch that in if such an option isn't there already May 21 13:32:16 bluelightning: Ok, I have think to this solution, but that's seem a little weird to do "custum" option for one standard feature. May 21 13:35:56 mad_jeff: I'm assuming there is a variable you could use to get the sysroot, I don't happen to know what it is off the top of my head (I was hoping that rburton would know, but I guess he isn't around) May 21 13:36:10 a variable on the autoconf side, I mean May 21 13:37:39 bluelightning: I have the same hope. I will check something I come back later May 21 13:43:19 bluelightning : Ok my check is a fail ;) I will do a specific parameter. And come back to this problem when I have more time. Thanks for your support May 21 14:49:25 rburton: I will review the fitImage serie May 21 14:53:48 using meta-java and building java-test-image in dizzy I get this error on rhino1: OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure May 21 14:53:52 any clue? May 21 14:58:07 wget fails but download from the browser works, where can I place the .zip now? May 21 15:00:15 mckoan: you can put it in DL_DIR and touch .done May 21 15:01:03 bluelightning: in fact I put it in DL_DIR, missing the touch May 21 15:01:08 anyone around familiar with meta-raspberrypi? i'm trying to add a device connected to the gpio header, so i'm starting to write a device tree (dts). i'm using kernel 3.18 so it should be supported, but i'm not sure how to do it? May 21 15:01:59 i've set KERNEL_DEVICETREE to "devicetree.dtb", and now the kernel build fails "no rule to make target 'arch/arm/boot/dts/devicetree.dtb' May 21 15:02:45 KERNEL_DEVICETREE is for the dts filename, not dtb May 21 15:02:49 iirc anyway May 21 15:02:55 so change it to devicetree.dts May 21 15:03:38 kergoth: i've seen that in other bsp's, but in meta-raspberry/conf/machine/include/rpi-base.inc the example lists .dtb files May 21 15:03:58 well the error clearly indicates thats wrong May 21 15:04:10 https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/include/rpi-base.inc May 21 15:06:52 ok, changing "devicetree.dtb" to "devicetree.dts" i get the same error, but another path: make[2]: *** No rule to make target `devicetree.dts'. Stop. May 21 15:15:29 did you put the device tree into the kernel sources? at the moment linux-dtb.inc doesnt' support building out of tree device tree files May 21 15:18:26 kergoth: nope. i'm a bit unsure how/where to install it ... May 21 15:18:49 should i put it in arch/arm/boot/dts/? May 21 15:42:40 khem, ping May 21 16:05:40 armpit: hello May 21 16:55:37 khem, when I do 'bitbake gcc -c devshell' from a clean install, there are no sources. gcc-sources are run after that step. is that by design or a bug? May 21 16:56:02 bug I presume May 21 16:56:08 well no May 21 16:56:37 usually devshell is run after do_patch May 21 16:56:50 so yeah it could be May 21 16:57:05 k, I will poke at it a bit more May 21 18:00:00 would be trivial to add an extra depends flag for do_patch in addition to the ones for the other tasks, i expect May 21 18:20:30 Hello I'm wondering if anyone can help me with a problem with creating a recipe for a shared library and then using that shared library in a recipe for an application. May 21 18:22:24 mschuckmann: why don't you try to write a recipe yourself? May 21 18:23:35 lpapp: I have written both the recipes, and I'm getting a strange error that I don't understand. May 21 18:23:52 what error exactly? May 21 18:24:38 lpapp: The recipe for the application using the shared library is giving me this error: ERROR: QA Issue: scp-daemon rdepends on libplnrprotocol-dev May 21 18:25:07 ok, can you show the recipe? May 21 18:25:32 yes do you want me to post it here? May 21 18:25:33 but runtime dependency on build-time thing does not look good to me. May 21 18:25:47 -dev is build time dependency. May 21 18:27:09 exactly, I must be doing something wrong. in the application recipe I've tried DEPENDS = "cmake-native boost libplnrprotocol" and RDEPENDS_${PN} = "libplnrprotocol" and i get the same error. May 21 18:27:28 I don't understand why it's trying to pick up the -dev package. May 21 18:27:55 hmm, perhaps pastebin the recipes. May 21 18:28:03 Ok one second. May 21 18:29:35 Here is the pastebin for the library recipe: http://pastebin.com/0YrVGuzA May 21 18:30:49 why do you need 29-33? May 21 18:31:20 and the application recipe: http://pastebin.com/PjRcyRnY May 21 18:32:42 I've found that I need 29-33 because the library is only built as ${libdir}/libplnrprotocol.so and the default in package.bbclass only looks for files of the form ${libdir}/lib*.so.* May 21 18:32:44 mschuckmann: I think you mean RDEPENDS for the library May 21 18:32:50 as it is a runtime dependency, isn't it? May 21 18:33:29 also, is boost really a runtime dependency? May 21 18:33:34 are you using header only parts of it? May 21 18:34:34 I am using both the header and runtime parts of boost (boost-program-options is a so library) May 21 18:35:42 I've tried putting libplnrprotocol in both DEPENDS and RDEPENDS_${PN} and I get the same error. May 21 18:36:39 yes libplnrprotocol is a runtime dependency, there are header files that need to be there for building. May 21 18:38:27 do not put it into DEPENDS at all is what I mean :) May 21 18:39:28 ok that's what I thought I should do but I still get the error: ERROR: QA Issue: scp-daemon rdepends on libplnrprotocol-dev May 21 18:41:00 unfortunately, I need to leave now, but hopefully someone can help. May 21 18:41:07 ok thank you May 21 18:57:15 If anyone is still listening, I've determined that my shared library package libplnrprotocol depends on it's own -dev package, what I don't understand is why? May 21 19:05:17 by default the .so goes into the -dev package because most sane libraries set SONAME properly May 21 19:05:26 .so is generally a development-only symbolic link May 21 19:11:13 Ok I can adjust my library to be sane, will that solve my problem of libplnprotocol rdepending on libplnrprotocol-dev? May 21 19:27:24 mschuckmann: yes May 21 19:28:23 rburton: Thanks I just verified that it does solve my problem. May 21 19:28:44 kergoth: Thanks that solved my problem. May 21 19:31:28 np May 21 20:27:14 * zeddii notices that the archiver isn't doing quite what I expect in master. May 21 20:27:22 I'll have to check for changes. May 21 20:27:54 I thought that if you built it, it was deployed and archived .. but not in my test I just ran. only if it was installed to an image. May 21 21:03:48 zeddii: hmm, that sounds like it's broken May 21 22:35:55 kergoth: Have you any thoughts on what something like RDEPENDS_${PN} = "X", SOMEPN = "${PN}", RDEPENDS_${SOMEPN}_append = "Y" should do? May 21 22:36:36 kergoth: I'm looking at removing update_data but this has some interesting implications for expressions like the above :/ May 21 22:37:04 updated-rc.d and its RRECOMMENDS is the main offender being reported May 21 22:37:30 hmm, that's rather unpleasant May 21 22:38:08 not sure i've had enough caffeine to be useful, the baby decided 4:45 was a good time to be (and stay) wide awake this morning May 21 22:38:28 kergoth: not good :( May 21 22:39:24 kergoth: the other issue I'm struggling with is I started stashing potential overrides in a flag against variables. Now variables called "set", "find" and "copy" exist and its making a right mess of the variable dependencies May 21 22:39:44 kergoth: then bitbake -e crashes as "copy" is an internal name as far as COW is concerned May 21 22:43:48 sounds like a bug in the COW implementation May 21 22:43:55 not that knowing that is very helpful May 21 22:45:23 kergoth: its more the way COW was implemented. Very hard to change without loss of performance May 21 22:45:56 I can't help but wonder if we'd be better off implementing the COW in cython or something rather than abusing classes the way we do May 21 22:45:59 heh May 21 22:47:03 kergoth: would be interesting to see what the performance difference was May 22 02:50:25 does anyone know what redudant rpath error means. It looks like this May 22 02:50:26 QA Issue: opencv: /work/corei7-64-poky-linux/opencv/3.0.0-r0/packages-split/opencv/usr/lib64/libopencv_superres.so.3.0.0 contains probably-redundant RPATH /usr/lib64 [useless-rpaths] **** ENDING LOGGING AT Fri May 22 02:59:58 2015