**** BEGIN LOGGING AT Mon Mar 21 02:59:58 2016 Mar 21 03:44:02 i have a question, it is i add package i2c-tools by IMAGE_INSTALL in local.conf (core-image-x11.bb also tried), after compile deploy image, the download to sdcard to boot arm board, and get error : sh: cannot set terminal process group (-1): inapropriate ioctl for device, so how to solve it? why Mar 21 03:55:42 expect answer for my question. what confict for i2c-tools with sth in kernel Mar 21 04:06:24 zxc678: installing i2c-tools seems like an unlikely trigger for such a bootup error Mar 21 04:06:46 zxc678: have you tried commenting that out again to see if it's really that? Mar 21 04:42:03 no, shell not work ,so i cant try it Mar 21 04:45:32 the last output lines is Mar 21 04:46:12 freeing unused kernel memeory:328k(80d23000-80d75000) Mar 21 04:46:38 sh: cannot set terminal process group (-1) : inappropriate ioctl for device Mar 21 04:46:46 sh: no job control in this shell Mar 21 04:46:53 sh-4.3# Mar 21 04:47:15 shell not wok, i cant input command to try anything Mar 21 04:48:51 ok, i also delete the IMAGE_INSTALL += "i2c-tools", then recomplie and run image, it work well Mar 21 04:49:05 so the issue is from i2c-tools Mar 21 04:53:12 bluelightning: and then? Mar 21 05:17:42 zxc678: it sounds a bit like for some reason the init system isn't being started, instead you're being put into a shell Mar 21 05:17:47 I have no idea why that would be the case Mar 21 05:22:51 zxc678: oh, I think I figured it out Mar 21 05:23:21 zxc678: I suspect that IMAGE_INSTALL is trashing your initramfs because it applies to every image built by the system (which includes the initramfs) Mar 21 05:23:52 zxc678: I would suggest CORE_IMAGE_EXTRA_INSTALL += "i2c-tools" instead Mar 21 05:24:21 zxc678: even better, create your own custom image recipe instead - it's trivially easy, just copy the image recipe you want to start with and edit it Mar 21 08:32:50 good morning Mar 21 08:38:40 I will try, thanks Mar 21 11:03:55 Hi. Does PREMIRROR actually mirror git repositories? As far as I can see, it doesn't, unless BB_GENERATE_MIRROR_TARBALLS is used. Is that correct? Mar 21 11:14:50 the mirror needs to use that variable, yes Mar 21 11:17:40 rburton: isn't it possible to make the mirror provide a git repo that can be cloned by the requester? The scenario I have here is a dedicated build environment which doesn't actually build, only runs "bitbake -c fetchall image" to populate DL_DIR, which is shared among the actual builders. Mar 21 11:18:52 But requests for git repos are not resolved in the mirror, so builders end up fetching from upstream repos. Mar 21 11:19:34 IIUC, BB_GENERATE_MIRROR_TARBALLS would generate a tarball for each revision in SRCREV, right? Mar 21 11:22:22 erm, pass. Mar 21 11:27:09 Ok, thanks anyway. Mar 21 12:29:49 is it just my impression, or has it become easier to use oe/yocto with arch linux? Mar 21 12:29:53 in the past, it was a complete disaster Mar 21 13:52:21 dv_: other distros have caught up and arch hasn't yet gone blazing ahead yet Mar 21 13:52:35 its not like arch is the only distro shipping gcc5, for example Mar 21 13:53:09 the the most recent "build breaks on my host distro" was on gentoo, so arch is slacking to be honest Mar 21 15:21:06 mario-goulart: premirrors should be able to handle fetching from an actual git repo mirror, if the right side resolves to a git:// uri Mar 21 15:29:36 kergoth: you mean it cannot be a file:// uri? (It is in the current case, as it is an NFS share). Mar 21 15:29:48 you're misunderstanding how the fetcher works Mar 21 15:29:58 the url scheme controls which fetcher is used, not the underlying communications protocol Mar 21 15:30:05 file:// will literally just copy some files locally Mar 21 15:30:09 git:// will use git Mar 21 15:30:18 if you want to fetch a local git repo, use ;protocol=file on the end of the uri Mar 21 15:30:34 I see. Thanks for the explanation. Mar 21 15:30:36 np Mar 21 15:30:53 Would that work for svn too? Mar 21 15:30:54 looking back, it'd be nice to support the + separated scheme which is used by lots of projects nowadays Mar 21 15:30:59 i.e. pip will use git+https:// Mar 21 15:31:13 good point Mar 21 15:31:16 not sure offhand, you could check the svn fetcher code Mar 21 15:31:26 or just try it :) Mar 21 15:31:33 Will do. Thanks again. :-) Mar 21 15:31:49 np Mar 21 15:33:31 the use of scheme for fetcher does lead to confusion, perhaps we should have gone the other way around, i.e. file://foo.git;fetcher=git, or something, but it's a bit late for that now :) Mar 21 15:35:08 :-) Mar 21 16:11:42 After adding meta-q5, what is the process to add eglfs as a platform aside from xcb, minimal, offscreen, etc. Mar 21 16:11:45 ? Mar 21 16:42:23 JaMa: are you aware that the oe patchwork appears to have no patches in? Mar 21 16:42:58 rburton: quick ship it, its DONE :-D Mar 21 19:36:10 I have a recipe that for some reason isn't going through the installation to sysroot prior to a dependency running through it's configure task. The recipe inherits from nothing and only implements do_install, where it throws an executable to the STAGING_BINDIR_CROSS and some headers over to the STAGING_INCDIR. Is there a better way to do this that will ensure these steps happen before a dependent tries to run configure? Mar 21 19:43:55 eengie: the recipe should not be poking things directly into those directories within do_install Mar 21 19:44:08 eengie: the correct way to do it is to install to the appropriate location under ${D} Mar 21 19:44:27 from there, a select list of directories get automatically staged to the sysroot Mar 21 19:51:56 bluelighting: thanks! Mar 21 19:54:12 bluelightning: actually though, what would be the appropriate ${D} for something that is going to be executed from the STAGING_BINDIR_CROSS (i.e., native to the build host)? Mar 21 19:54:37 look at one of the many existing -cross recipes we have Mar 21 19:54:46 Alright Mar 21 19:55:25 eengie: ${D}${bindir_crossscripts} I believe Mar 21 20:07:15 rburton: what you mean by no patches? Mar 21 20:07:32 rburton: I was taking few patches from it today Mar 21 20:07:48 rburton: are you aware that patches are marked as archived after they are sorted to separate bundles? Mar 21 22:02:21 WARNING: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf-core/tests/attr.py contained in package perf requires /usr/bin/python, but no providers found in RDEPENDS_perf? [file-rdeps] Mar 21 22:05:47 yeah thats been annoying me for ages Mar 21 22:05:49 there a bug somewhere Mar 21 22:06:21 in bugzilla? Mar 21 22:06:23 yes Mar 21 22:06:29 k Mar 21 22:06:32 I just saw it Mar 21 22:06:45 first question is why does perf need something called /tests/ Mar 21 22:08:05 some many problems, so little time Mar 21 22:09:40 Crofton: i have that fixed in meta-mentor Mar 21 22:10:06 two fixes, one to fix the files to go into the subpackages properly (it hardcodes lib/perf rather than using libexecdir in FILES), and the other to fix the 'python2' thing Mar 21 22:10:15 will add to the list to submit to oe-core Mar 21 22:11:14 thanks kergoth Mar 21 22:11:22 +1 Mar 21 22:11:32 https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/recipes-kernel/perf/perf.bbappend Mar 21 22:11:41 also need to push the bits to obey LD while i'm at it Mar 21 22:14:12 is there a problem with boost-atomic in sdks? **** ENDING LOGGING AT Tue Mar 22 02:59:58 2016