**** BEGIN LOGGING AT Fri Apr 05 02:59:58 2013 Apr 05 06:44:24 is there any alternative to core-utils that provide nice ? Apr 05 06:50:13 good morning Apr 05 06:52:23 erbo: you can enable it in busybox I believe Apr 05 06:52:48 morning mckoan, erbo, all Apr 05 06:53:01 morning Apr 05 06:53:08 bluelightning: thanks Apr 05 09:44:28 build #89 of nightly-ppc-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-ppc-lsb/builds/89 Apr 05 09:52:22 hello, i have imx6sabresd. it have 2 cams (/dev/video0, and video1) then i run gst-launch mfw_v4lsrc ! autovideosink - all good, but then i run gst-launch autovideosrc ! autovideosink i got errors. Maybe I missed a plugin? Apr 05 09:55:52 depends on what the errors are really Apr 05 09:56:11 or, the mfw_v4lsrc doesn't want to autoplug Apr 05 10:03:54 root@imx6qsabresd:~# gst-launch autovideosrc Apr 05 10:03:54 Setting pipeline to PAUSED ... Apr 05 10:03:54 Pipeline is PREROLLED ... Apr 05 10:03:54 WARNING: from element /GstPipeline:pipeline0/GstAutoVideoSrc:autovideosrc0: Resource not found. Apr 05 10:03:54 Additional debug info: Apr 05 10:03:55 /home/alexei/lastimx6/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gst-plugins-good/0.10.31-r8/gst-plugins-good-0.10.31/gst/autodetect/gstautovideosrc.c(315):: Apr 05 10:03:58 Failed to find a usable video source Apr 05 10:03:59 ERROR: from element /GstPipeline:pipeline0/GstAutoVideoSrc:autovideosrc0/GstFakeSrc:fake-video-src: Internal data flow error. Apr 05 10:04:02 Additional debug info: Apr 05 10:04:04 /home/alexei/lastimx6/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasesrc.c(2625): gst_base_src_loop : Apr 05 10:04:07 streaming task paused, reason not-linked (-1) Apr 05 10:04:09 ERROR: pipeline doesn't want to preroll. Apr 05 10:04:11 Setting pipeline to PAUSED ... Apr 05 10:04:15 Setting pipeline to READY ... Apr 05 10:04:17 Setting pipeline to NULL ... Apr 05 10:04:19 Freeing pipeline ... Apr 05 12:02:35 is there any formalization for when one has to nuke a build directory after updates? (at the moment I get a conflict between rpm vs rpm-postinsts after doing a git pull of oe-core) Apr 05 12:03:00 should one just generally start from a clean build directory for tracking oe-core, and re-edit local.conf? Apr 05 12:19:22 incremental builds shouw be fine Apr 05 12:53:57 walters: as long as bitbake does not complain that you have to bump version in config files it should be safe Apr 05 12:54:23 in this case it looks like there was a conflict between rpm and rpm-postinsts in the sysroot Apr 05 12:54:30 worked after i blew away tmp-eglibc Apr 05 12:55:21 not a big deal, just curious how others worked Apr 05 13:33:12 build #89 of nightly-ppc is complete: Failure [failed Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-ppc/builds/89 Apr 05 14:19:21 RP2: Commit a0bd02db2d2341c0a496e9bbd6e8a0ab7e7cd83e causes the following fine message when running oe-init-build-env: cat: /home/pkj/yocto/poky/meta-yocto/conf/conf-notes.txt: No such file or directory Apr 05 14:19:42 Saur: and a subsequent commit fixes it? Apr 05 14:20:24 Saur: http://git.yoctoproject.org/cgit.cgi/poky/commit/meta-yocto/conf/conf-notes.txt?id=fd4e5c6c58183f1a017c6b5fe4d43c320e273567 Apr 05 14:21:09 RP2: Ah, hadn't pulled the last commits. :) Apr 05 14:22:54 RP2: Still, I think the cat line should read: [ ! -r "$OECORENOTESCONF" ] || cat $OECORENOTESCONF Apr 05 14:23:13 Saur: agreed, I'd take a patch Apr 05 14:44:16 RP2: I assume patches for oe-setup-builddir should go to openembedded-core@lists.openembedded.org rather than yocto@yoctoproject.org? Apr 05 14:44:40 Saur: correct Apr 05 14:45:41 RP2: I'll pass along two other small patches related to oe-init-build-env while at it... Apr 05 15:21:16 RP2: Hmm, you seem to have a script called create-pull-request that seems to be the way to easily format patches for distribution. However, it seems to require that I first push my changes to poky-contrib. Can anyone get write access there, or am I limited to create the mails manually? Apr 05 15:30:16 Saur: you need to send an ssh key to halstead Apr 05 15:31:14 Saur you can e-mail michael@yoctoproject.org with your ssh public key. Apr 05 15:32:04 havefun Apr 05 15:34:38 bluelightning: how often are layers "reparsed" for layerindex? Apr 05 15:35:30 halstead: Sent Apr 05 15:35:38 JaMa: every 3 hours at the moment Apr 05 15:36:18 thanks Apr 05 15:36:28 havefun Apr 05 15:36:44 havefun Apr 05 15:36:45 * JaMa waiting for meta-webos-ports reparse Apr 05 15:37:07 havefun Apr 05 15:37:15 asdasdr Apr 05 15:37:18 blitz00: :))) Apr 05 15:37:35 it would be nice if the web interface itself could trigger the reparse but that would require some kind of background processing framework Apr 05 15:38:06 of which there are many already in existence, but integrating such a thing is not a trivial exercise Apr 05 15:39:36 bluelightning: current implementation is good enough for me, this is just exception when I expect a lot of changes from meta-webos-ports Apr 05 15:52:11 JaMa: I presume it now has a conf/layer.conf? Apr 05 15:52:25 the update script has been complaining at me about it... Apr 05 15:53:17 bluelightning: it had conf/layer.conf even before Apr 05 15:53:53 bluelightning: but now it contains our meta-webos fork as well as old meta-webos-ports Apr 05 15:54:25 JaMa: ah... now I see what's happening Apr 05 15:54:42 JaMa: the meta-webos-ports layer index entry points to the webos-ports-setup repo Apr 05 15:54:49 that does not contain a layer Apr 05 15:55:07 and branches were renamed to match required layers (master is now correctly danny and new master is compatible with master branches) Apr 05 15:55:17 ah :/ my fault not sure how I messed it Apr 05 15:55:19 fixing it now Apr 05 15:55:27 thanks, that should work better :) Apr 05 16:11:39 build #94 of nightly-x86-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86-lsb/builds/94 Apr 05 17:01:37 RP2: There, sent my first patches to oe-core. I hope I got it right... :) Apr 05 17:06:46 Saur: looks good, thanks :) Apr 05 17:07:18 Saur: in future try and be a bit more verbose in the commit message. Those ones are quite obvious but we're trying to get people to explain changes more... Apr 05 17:07:42 RP2: No problem. Apr 05 17:08:37 RP2? 2? Did the cloning finally work? \o/ Apr 05 17:09:14 dvhart: I've no idea why I'm that far back on the fallbacks :) Apr 05 17:09:28 ;) Apr 05 17:31:55 dvhart: I have the EFI booting working properly with my out of tree mechanism that uses a USB image with two partitions. Apr 05 17:32:14 This is the same scheme I was proposing to use to replace the whole linux live with the hdd image. Apr 05 17:32:39 jwessel, how is it different from mkefidisk.sh ? Apr 05 17:32:54 I am afraid I don't know what mkefidisk.sh is. Apr 05 17:33:07 oe-core/scripts/contrib/mkefidisk.sh Apr 05 17:33:11 I believe you mentioned it to be before, but I had not checked it out. Apr 05 17:33:24 it deploys hddimg's to a device with 2 partitions, etc Apr 05 17:33:47 I also resurected the working ISO EFI image stuff too. Apr 05 17:33:55 nice Apr 05 17:34:11 I'll get it all loaded into the BZ case next week hopefully. Apr 05 17:34:29 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4100 Apr 05 17:34:30 Bug 4100: enhancement, Medium+, 1.5, dvhart, ACCEPTED , Add EFI support to ISO images Apr 05 17:34:40 * dvhart hugs yocti Apr 05 17:34:43 Yup. I know the number since I wrote it ;-) Apr 05 17:35:02 ah, right :-) Just making sure we were connected and looking at the same things Apr 05 17:38:06 after seeing the mkefidisk, the version I have is quite a bit more complex. Apr 05 17:38:26 It does things like writing the image to a file, and doesn't use a hddimage. Apr 05 17:38:45 In addition to supporting writing something directly to a disk. Apr 05 17:39:09 I am not saying that the complexity is good or bad of course. Apr 05 17:55:56 any idea how to fix the python's ctypes.util? Apr 05 17:56:16 which can't pass its own test Apr 05 17:56:56 and for a linux which it doesn't have ldconfig/gcc installed on target, it will not work at all I guess Apr 05 18:01:29 hmm latest curl from oe-core is segfaulting quite a lot :/ Apr 05 18:01:58 https://github.com/bagder/curl/commit/da3fc1ee91de656a30f3a12de394bcba55119872 should fix it Apr 05 18:16:34 kinda silly bug :-( Apr 05 18:18:05 ah bagder is here :) Apr 05 18:18:36 * JaMa testing patched recipe now Apr 05 18:19:05 the next curl release will happen next week though Apr 05 18:19:26 just a fyi Apr 05 18:20:24 good, but I think that for oe-core release it will be safer to backport just one patch than upgrade it just before release Apr 05 18:20:44 unless you know about more dangerous bugs in 7.29 Apr 05 18:24:14 the bug fixes donce since 7.29 are basically the ones listed at http://curl.haxx.se/dev/release-notes.html, but I can't think of any as "dangerous" as that one Apr 05 18:25:00 but yes, I agree that a single patch is much safer Apr 05 18:33:49 any suggestion for the ctypes.util? Apr 05 18:34:40 the ctypes.util.find_library can't find anything find_library("m") to look for libm Apr 05 18:38:50 donn:"strace.do_configure" -> "wrl-glibc-prebuilt.do_populate_sysroot" Apr 05 19:07:57 hello, is master now is broken? when i try build qt4e-demo-image i've got error: Apr 05 19:07:58 ERROR: Recipe rpm-postinsts is trying to create package rpm-postinsts which was already written by recipe rpm. This will cause corruption, please resolve this and only provide the package from one recipe or the other or only build one of the recipes. Apr 05 19:07:59 ERROR: Function failed: read_subpackage_metadata Apr 05 19:07:59 ERROR: Execution of event handler 'run_buildstats' failed Apr 05 19:07:59 T Apr 05 19:23:07 alex_kag: you need to clean rpm first Apr 05 19:23:54 alex_kag: http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=7841ee7041d04f11a3d879fb5bc60bb37de0a5c0 moves it from rpm to separate recipe, but with incremental build it will find old rpm-postinsts in pkgdata Apr 05 19:25:20 i should manualy delete build/tmp/deploy/rpm? Apr 05 19:26:26 alex_kag: bitbake -c clean rpm Apr 05 19:29:08 does yocto have recipe for asciidoc? Apr 05 19:33:39 and whether there were any pitfalls in the transition to deb packages? Apr 05 19:38:08 alex_kag: you're switching from rpm to deb? the deb backend is less well tested. Apr 05 19:39:22 if its so, i don't want switch :) Apr 05 19:43:24 you can switch to ipk Apr 05 19:51:34 is there some plan to create public PR service server? at least to test work load and scallability of PR service code? Apr 05 20:06:50 did someone report issues like this /usr/bin/objcopy: Unable to recognise the format of the input file `/OE/systemd-1_199-r0/systemd-199/.libs/lt-systemd' few days ago? I cannot find that email now Apr 05 20:48:52 zedii: feedback sent Apr 05 20:49:42 ant_home, sounds good. I'll look at it later. I'm looking into a related issue, so I hope it's 1 fix for 2 problems. Apr 05 20:49:51 nice Apr 05 22:21:22 I have question which probably is simple, however I can't figure it out. I know I can assign which version of the kernel I want with my machine.conf file. Is there a way to have a single machine support multiple kernels and pass PREFERRED_VERSION_linux-yocto to bitbake on the command line? Or do I need to have different machine.conf files? Apr 05 22:21:56 use ?= in machine.conf, then you can override it in local.conf Apr 05 22:22:08 ?= is 'set only if it isn't set already' Apr 05 22:22:43 I'd like to not modify any .conf files. but pass on the command line so I can do automated builds.. one version of the kernel then next run the other version. Apr 05 22:23:17 version is NOT set in any .conf files. they are all ?= defines Apr 05 22:25:36 bitbake implicitly supports passing any env var into the metadta, it just blacklists them all excepting a certain whitelist for safety Apr 05 22:25:49 see the documentation on BB_ENV_EXTRAWHITE to learn how to add PREFERRED_ERSION_linux-yocto to it. Apr 05 22:25:55 alternatively, just write conf/auto.conf in your build dir Apr 05 22:25:57 yeah.. kind of like MACHINE. Apr 05 22:25:59 thanks Apr 05 22:26:06 that is always parsed, and it exists specifically for automated builders Apr 05 22:26:14 np Apr 05 22:44:16 kergoth: there is the small issue that the shell doesn't like "-" in variable names... Apr 05 22:45:02 * RP_ has been bitten before :/ Apr 05 22:45:28 ugh, good point, didn't think about that Apr 05 22:47:20 so just assign it to another variable and pass that in... Apr 05 22:47:45 or use auto.conf and keep your sanity :) Apr 05 22:48:08 indeed **** ENDING LOGGING AT Sat Apr 06 02:59:58 2013