**** BEGIN LOGGING AT Thu Mar 13 02:59:58 2014 Mar 13 06:59:06 how to i provide library option -lrt while doing bitbake Mar 13 07:00:05 I am trying to do bitbake helloworld -fC compile -lrt Mar 13 07:00:28 but getting helloworld.c:(.text+0x1c): undefined reference to `shm_open' Mar 13 08:42:09 good morning Mar 13 09:11:12 \ Mar 13 12:08:54 hi, is the yocto core image supposed to have the correct date on the board even if it is flashed much later than when it was created? Mar 13 12:19:27 it seems that the date gets stuck whenever the image was created. Mar 13 12:19:39 so the logs on my system can be misleading... Mar 13 12:19:42 is there a way to fix it? Mar 13 12:20:04 (without running ntp) Mar 13 12:20:21 lpapp: if the time is being reset to the time in the stamp then your rtc is wrong Mar 13 12:20:37 because its using the timestamp as a lower-bound Mar 13 12:20:49 (as obviously the current time can't be before the image creation time) Mar 13 12:21:22 here is where i endorse connman, as you can get it to do ntp when it discovers a connection Mar 13 12:21:53 our devices are not meant to be connected to the internet... Mar 13 12:22:10 so there must be a better option than syncing up with the internet... Mar 13 12:22:20 I will take a look at the real-time clock, thanks. Mar 13 12:22:28 (that should work if the hardware works, right?) Mar 13 12:22:40 you'll need to set it once, obviously, but yes Mar 13 12:22:44 if the hardware works you should be fine Mar 13 12:23:32 cannot Yocto be configure to do it automatically? Mar 13 12:23:43 on first boot for instance? Or the init system underneath does not support it? Mar 13 12:24:05 oh, but it would not know the real-time. Mar 13 12:25:04 yeah. you could set the rtc at assembly time and include a battery to keep the clock running. Mar 13 12:25:09 I wonder how other vendors handle this question when using Yocto. I guess this is somehow built into the workflow. Mar 13 12:25:38 its orthogonal to yocto really - it's a general "how do i set the time on my product" thing Mar 13 12:26:00 if you're expected to have networking its trivial, if no networking but you also need an accurate clock them less easy Mar 13 12:26:00 yeah. its just a question of deploying software + defaults on the devices in manufacturing Mar 13 12:26:47 you could even set the rtc through direct i2c injection in some automated programming environment or such Mar 13 12:28:20 (if its an i2c rtc of course) Mar 13 12:28:21 rburton: I think the best will be to sync up the target with the flashing machine. Mar 13 12:28:48 lpapp: yeah, flash the image and program the clock at the same time Mar 13 12:29:07 ERROR: debugedit failed with exit code 256 (cmd was '/home/jenkins/workspace/fsl-community-bsp-master/build/tmp/sysroots/x86_64-linux/usr/lib/rpm/bin/debugedit' -b '/home/jenkins/workspace/fsl-community-bsp-master/build/tmp/work/imx23evk-poky-linux-gnueabi' -d '/usr/src/debug' -i -l '/home/jenkins/workspace/fsl-community-bsp-master/build/tmp/work/imx23evk-poky-linux-gnueabi/perf/1.0-r8/debugsources.list' '/home/jenkins/workspace/fsl-community-bsp-ma Mar 13 12:29:14 is ths known? Mar 13 12:29:30 .. will only get you somewhere if you can ensure constant buffering the rtc's power rails from the point of programming Mar 13 12:29:46 rburton: yes, in the same manufacturing workflow, but it needs to be hidden for the manufacturing. Mar 13 12:30:09 so once the image is flashed over u-boot, and it is booted, we need to get a tool doing this over ssh. Mar 13 12:30:09 some people need their backup batteries disconnected until final installation or such. Mar 13 12:31:38 rburton: the best would be to do it at u-boot time when the kernel is also flashed, but that is yeah... not a yocto question. Mar 13 12:31:51 that way, I could avoid waiting for the system to launch... Mar 13 12:31:59 but I am not sure if u-boot supports it. Mar 13 12:33:35 ah, there is a date command in u-boot! Mar 13 13:03:03 rburton: I used date xxx and then hwclock -w, then I checked with hwclock -r that it returns what I set up... but after a reboot, I am still getting the fallback provided by Yocto. :/ Mar 13 13:03:06 what am I doing wrong? Mar 13 13:04:04 honestly its been years since i looked at this bit of the boot. what does hwclock -r say after a reboot? Mar 13 13:04:28 sorry, I used the linux kernel for it Mar 13 13:04:30 so I skipped u-boot... Mar 13 13:06:25 oh, it worked for the second time, second reboot, interesting. :-) Mar 13 13:06:38 might well be a kernel bug or something. Mar 13 13:07:20 considering the amount of use that the hwclock gets (every power cycle for example) i'd be surprised if it just broke and nobody noticed Mar 13 13:07:57 you would think that, yes. :) Mar 13 13:09:51 let me reflash and see if I can reproduce it. Mar 13 13:59:34 rburton: it is interesting that ntp is not in oe-core, but meta-networking. Mar 13 13:59:46 I would have thought it is an essential feature for the majority. Mar 13 14:22:11 hello i would like to disable webkit module from qt4_x11_free, so i put -no-webkit in QT_WEBKIT var... So i can see that this flag is given to the configure args but webkit is still built. Indeed QT_CONFIG contains webkit Mar 13 14:22:33 does someone succeeds to disable webkit build in QT4.8.5 in yocto ? Mar 13 14:28:17 it seems that qt is taking my local conf but i dont know why Mar 13 14:38:53 hi. i've created a custom image recipe now that inherits image.bbclass (not core-image.bbclass, until i fully understand what image.bbclass does). IMAGE_INSTALL is "packagegroup-core-boot". Mar 13 14:39:59 sce: what is your local.conf? Mar 13 14:40:23 lpapp, what do you mean ? Mar 13 14:40:39 sce: share more information about your issue if you are still looking for help. :) Mar 13 14:40:44 ionte: ok, do you have a question? Mar 13 14:40:58 this builds, but when i try to boot the image using "runqemu qemux86" it complains that: Couldn't find a qemux86 rootfs image in ... Mar 13 14:41:54 i can't see any obvious difference between my minimal image recipe and core-image-minimal for example Mar 13 14:42:44 lpapp, here it is http://pastebin.com/V5TFgq1k :) Mar 13 14:43:59 lpapp, it seems that the build takes some local information (/usr/share) to get the qt features Mar 13 14:44:26 any ideas what i'm doing wrong? what is the name of the image file used by runqemu and how do i generate it? Mar 13 14:44:45 MACHINE is qemux86 btw... Mar 13 14:52:01 lpapp, i'm having in /usr/share/qt4/mkspecs/modules/ a file named qt_webkit_version.pri Mar 13 14:52:31 if i rename this file to another name webkit is not in my QT_CONFIG Mar 13 14:52:45 so it seems that qt build in yocto is not independent from the system Mar 13 14:55:15 http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-support/ntp/ntp.inc#n77 Mar 13 14:55:25 so why does ntp depend on tickadj which should not be used on Linux? Mar 13 14:57:20 got qemu working by specifying the full path to kernel and ext3 image files Mar 13 14:58:52 why dont we use sysroot in qt build ? Mar 13 15:18:23 it seems that if i remove the package qtwebkit-dev from my ubunut Mar 13 15:18:29 webkit is correctly disabled Mar 13 15:18:51 but i dont understand why qmake looks for my QT machine information Mar 13 15:19:04 it probably looks too hard for webkit and finds it on your host Mar 13 15:19:11 tell jama Mar 13 15:29:25 rburton: sce is building qt4 so it's not specifically Martin Mar 13 15:44:40 bluelightning: confirmed, fyi. ever since the change to how aclocal files are copied (based on dependencies), target m4 macros seem to more reliably be used in preference to native (which they should), but in a non-gplv3 build, gettext is 0.16 while gettext-naitve is 0.18, causing a 0.16 po.m4 to be used with our 0.18 po/Makefile.in.in files, causing at least some failed builds, including e2fsprogs. confirmed with just poky, current master Mar 13 15:45:21 hmm, maybe we can leave the target gettext macros out of the sysroot entirely, since anyone inheriting gettext gets both native and target built, autotools.bbclass could then just use the native ones Mar 13 15:45:51 course that assumes there's no compatibility problems using build tools from one version and libgettext* from another :) Mar 13 15:46:45 kergoth: ok... I wonder why we didn't see this Mar 13 15:46:51 kergoth: would you mind filing a bug for this issue? Mar 13 15:48:17 yeah, will do Mar 13 15:51:18 bluelightning: a Mar 13 15:51:25 bluelightning: ah, didn't notice qt4 Mar 13 15:52:27 rburton, i remember there is something to do with qt.conf Mar 13 15:53:13 which defines where qmake is looking for information **** ENDING LOGGING AT Fri Mar 14 02:59:59 2014