**** BEGIN LOGGING AT Wed Oct 29 03:00:00 2014 Oct 29 03:32:40 getting this error after switching to daisy: http://pastebin.com/J425kn6j any ideas? Oct 29 05:16:04 I am getting a: "shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory" error when trying to fetch a git submodule. Can anyone give me a hint on how to go about debugging such an issue? Oct 29 05:28:40 answer is, it was moderately difficult to add *xattr support, but it's there now. Oct 29 05:28:42 There's some issues with host contamination if you run under selinux, to which the official answer is "don't do that". Oct 29 05:31:40 will setting selinux to permissive avoid it? Oct 29 05:31:54 assuming you were speaking to me... Oct 29 05:33:54 guess the answer is no Oct 29 07:17:38 good morning .* Oct 29 07:56:23 lep4ss Oct 29 08:01:10 morning all Oct 29 08:05:10 morning Oct 29 08:06:13 I have some strange issues with fetching linux-yocto-3.10, it fails to get the git and then tries a mirror tarball. But that doesn't succeed either (claims it's not a git) Oct 29 08:06:44 looking at http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.10.git.tar.gz I see it's only 59M, which seems really small Oct 29 08:07:28 an older version of that from an old build it 800+M Oct 29 08:11:17 oh, downloading it and trying to untar results in: "gzip: stdin: unexpected end of file" Oct 29 08:17:54 erbo: can you please email michael@yoctoproject.org about that issue? Oct 29 08:17:56 I need to tweak certain things in the image, after installing the deb packages but before it creates jffs2 image, where can i hook this into? Oct 29 08:18:17 irontia: you can add commands to ROOTFS_POSTPROCESS_COMMAND Oct 29 08:18:31 That was fast. Thanks Oct 29 08:18:52 typically you'd define a shell function and then add a call to the function from that variable Oct 29 08:22:52 bluelightning: sure, I'll do that Oct 29 09:37:22 What is the proper way to start the build again after modifying an image recipe e.g. recipes-apple/images/apple-ios10-image-minimal.bb. When i execute bitbake again for that image it will just say "2088 tasks of which 2088 didn't need to be rerun" Oct 29 09:39:35 These recipes don't have versions and changes don Oct 29 09:39:43 ... 't seem to be tracked. Oct 29 09:45:12 irontia: You may try with "bitbake -f --no-setscene" Oct 29 10:32:52 irontia: what kind of change did you make? it should detect the change automatically Oct 29 10:35:04 Well, i added "ROOTFS_POSTPROCESS_COMMAND += "stripdown;" and the function stripdown. Oct 29 12:15:13 I am trying to run a custom image with runqemu + tap networking. That image expects to get an IP address via DHCP and changing that could be hard and make it different from real images. Have there been previous attempts to integrate a simple dhcp server into runqemu? Oct 29 12:15:32 IMHO that would make more sense then customizing the image for usage under qemu. Oct 29 12:25:11 pohly: I don't believe anyone has looked into that, but it would definitely be useful Oct 29 12:25:37 if you could file an enhancement request in our bugzilla that would be great Oct 29 14:29:12 In yocto libraries are only installed with full version and major-version name / symlink. I mean there are libICE.so.6.3.0 and libICE.so.6. But there is no symlink for libICE.so added into the package / rootfs. Why is this? I have an application that dlopens some so libs by the soname. But as there are no symlinks for them it fails. Now i wonder where the problem is. Should it dlopen libfoo.so.1 or should i manage to create the prope Oct 29 14:33:16 irontia, this is for zero-c ice? Oct 29 14:35:30 irontia: strictly speaking applications are not supposed to be linking to the unversioned .so file, that is intended for development Oct 29 14:35:40 hence that is normally packaged in the -dev package Oct 29 14:37:36 correct.. the normal soname mechanism allows a library linkage to reference the -actual- name of the so to ensure the correct version(s) are available on the system.. Oct 29 14:38:03 overriding this mechanism with a dlopen will cause the system to be unable to process package dependencies and will likely result in incorrect images being generated.. Oct 29 14:38:55 I've seen a few commercial apps that do this, and they 'claim' it's so they can support more distributions.. but apparently they've never heard of sonaming and version control in libraries because they've simply ported apps from Solaris or other UNIX systems that don't have as rich of a library versioning mechanism Oct 29 14:40:33 Thank you guys for the explanation. Makes sence. The software i am building has a module concept and the application and the modules are build in the same source tree. They never cared about so versions as it is always build alongside. Oct 29 14:40:36 Crofton|work: I think this would be libICE that's part of X11 Oct 29 14:41:25 ok Oct 29 14:41:28 just checking Oct 29 14:41:33 irontia: ah right, modules / plugins are a special case - typically the .so versioning would not be enabled for those Oct 29 14:42:09 yup.. but modules/plugins should not live in the normal libdir(s), but in subdirectories.. and as bluelightning said, without versioning info, the raw .so is preserved.. Oct 29 14:42:25 fray: right Oct 29 14:42:25 if you do need the .so w/o a version I believe you can add the soname entry for an unversioned SO.. Oct 29 14:42:39 that will cause the system to always have an unversioned symlink as well.. (with is perfect for plugins) Oct 29 14:43:48 I'm not sure I'd describe that as perfect... that still leaves you in a situation where you have to bypass our QA checks Oct 29 14:44:13 the QA checks look to see if the .so only in the libdir(s) Oct 29 14:44:29 something like /usr/lib/myapp-plugin/foo.so shouldn't trigger them Oct 29 14:44:34 but /usr/lib/foo.so will Oct 29 14:44:36 ah does it? I hadn't realised that Oct 29 14:44:49 (at least that is how I remember the tests being implemented) Oct 29 14:48:24 looking at the code, if you were to try to put that .so symlink in a non-dev package then it doesn't look like it would matter where it were installed, you'd still get the error Oct 29 14:48:40 ok.. then it's changed from what I remember.. Oct 29 14:50:16 but of course you can disable those checks (easily) :) Oct 29 14:59:54 I feel i learned something. I will transfer the plugin .so files to some /usr/lib/foo/bar.so location and see how that is handled. I'll let you know tomorrow ;-) Oct 29 15:06:13 Is the combination of systemd + busybox supported? systemd's getty .service files expect /sbin/agetty, but busybox only installs /sbin/getty, causing the service to fail - at least in my custom image. I have not tried generic Yocto. Oct 29 17:41:24 seebs, ping Oct 29 17:42:39 I updated to pseudo 1.6 on my yocto 1.3 image to test adding selinux support (before ultimately porting to yocto 1.7, but that tree isn't running yet). I'm hitting a curious problem. Oct 29 17:43:23 setfiles now *mostly* appears to work, but it is getting "deterministic" random failures. (ie. same files always fail, but there isn't anything I can see about them that is special): Oct 29 17:43:55 most files succeed, like this: Oct 29 17:43:58 setfiles reset /home/michael_e_brown/13g_selinux/build-yocto-sh4/tmp/work/idrac8-poky-linux/idrac-image-1.0.0-r0.0/rootfs/dev/mtd2 context ->system_u:object_r:device_t Oct 29 17:44:11 but some very small number of files fail, like this: Oct 29 17:44:16 setfiles reset /home/michael_e_brown/13g_selinux/build-yocto-setfiles get context on /home/michael_e_brown/13g_selinux/build-yocto-sh4/tmp/work/idrac8-poky-linux/idrac-image-1.0.0-r0.0/rootfs/media/realroot failed: 'No such file or directory' Oct 29 17:44:23 But the file actually exists: Oct 29 17:44:37 $ ls -la /home/michael_e_brown/13g_selinux/build-yocto-sh4/tmp/work/idrac8-poky-linux/idrac-image-1.0.0-r0.0/rootfs/media/realroot Oct 29 17:44:37 total 8 Oct 29 17:44:37 drwxr-xr-x 2 michael_e_brown michael_e_brown 4096 Oct 21 11:35 . Oct 29 17:44:37 drwxr-xr-x 10 michael_e_brown michael_e_brown 4096 Oct 29 12:35 .. Oct 29 17:45:25 When I strace the process, I see this: 22234 lstat("/home/michael_e_brown/13g_selinux/build-yocto-sh4/tmp/deploy/images/idrac-image-idrac8-20141029173411.rootfs.idrac/realroot", 0x7fff2f73aeb0) = -1 ENOENT (No such file or directory) Oct 29 17:45:36 It looks like it is trying to lstat() in the wrong directory Oct 29 17:46:11 when I run 'setfiles' with sudo, it works fine. but when I run with pseudo, it fails like this. Oct 29 19:41:43 Does a ".../usr/bin/python2.7.real: No such file or directory" error on SDK extraction ring any bell? Oct 29 19:42:18 I started getting that error out of sudden and can't get rid of it. Oct 29 19:45:15 which SDK? Oct 29 19:45:35 builttools-tarball, something you built with meta-toolchain, or -c populate_sdk or? Oct 29 19:45:49 -c populate_sdk for a custom image. Oct 29 19:46:16 close you login, come back in and try again.. I suspect you path has some stuff in it that is confusing the system.. (likely a project directory that had python stuff partially built) Oct 29 19:46:33 -or- the generated SDK got references to python wrappers it shouldn't have Oct 29 19:46:37 Oh! Good catch. Oct 29 19:53:27 Many thanks, fray. The polluted environment was the problem. You won't believe me, but right when I was about to test the sdk extraction from a clean shell, we had a power outage. So I _had_ to try it from a clean environment. :-) Oct 29 20:35:59 Hello everyone, is there anyone who could fix the broen tarball in http://downloads.yoctoproject.org/mirror/sources/ ? It causes anyone trying to build a kernel for Intel Edison board (3.10-based) to fail Oct 29 20:37:05 The file in question is git2_git.yoctoproject.org.linux-yocto-3.10.git.tar.gz, it's apparently broken - has on 59MB in size versus several hundred for other versions Oct 29 20:37:25 AlexT: hi there Oct 29 20:37:42 halstead, ping ^^^ Oct 29 20:38:05 someone else reported that this morning, I recommended emailing Michael (halstead) Oct 29 20:38:22 halstead, also montor this channel pretty good Oct 29 20:38:38 Thanks Crofton|work, AlexT, and bluelightning . I can remove that file now. Oct 29 20:38:45 :) Oct 29 20:39:02 * halstead is busy with the 1.7 release and a bit slow to respond. Oct 29 20:39:10 well, removing is good, but if you could get a correct one in addition, that would be great :) Oct 29 20:39:16 halstead: thanks Oct 29 20:39:17 * Crofton|work does not call a couple of minutes "slow" Oct 29 20:39:26 :) Oct 29 20:44:25 bluelightning, It looks like we had some git problems with clones of http://git.yoctoproject.org/git/linux-yocto-3.10 failing. Clones seem to work now. Oct 29 20:49:24 halstead, indeed, looks like it's fetching fine at least from the git repo now, I see the broken tar.gz is now gone. Thanks! That's good enough Oct 29 20:58:38 An fsck of the production git repo found no problems. Oct 29 21:01:29 out of curiosity, that git.tar.gz file is somehow autogenerated based on a scheduled git clone/fetch or something? git going crazy and tarball being broken looks like an interesting coincidence Oct 29 21:35:57 AlexT When the autobuilder runs it places the sources it grabs in a special location that is picked up by the mirror. Oct 29 22:26:37 hi Oct 29 22:28:55 I'm a building novice, wondering something: I have a Digi MX53 board, which I use to run Qt applications. I've been using the base system with Qt 4.7.2 because I don't have the knowledge to tamper with it. Would Yocto allow me to get a working Linux with a modern Qt (they're at 5.3 now), without breaking things like video, GPIOs, etc? Oct 29 22:30:18 I'm asking from the perspective of a novice...if it's possible, but requires hacking drivers left and right, then to me that's a no :/ Oct 29 22:54:21 hello guys Oct 29 22:54:34 anyone for help? Oct 29 22:55:03 hi Oct 29 22:55:16 anyone Oct 29 22:55:43 hello Oct 29 23:06:04 if you have a question, ask it Oct 29 23:12:10 getting this error after switching to daisy: http://pastebin.com/J425kn6j any ideas? Oct 29 23:30:52 hello Oct 29 23:30:57 #join **** ENDING LOGGING AT Thu Oct 30 03:00:00 2014