**** BEGIN LOGGING AT Thu Jan 10 02:59:59 2013 Jan 10 06:20:22 hello, i use oe-core to make a rootfs, but there is no libstdc++.so in the rootfs,but i find libstdc++6_4.7.2-r13_cortexa9hf-vfp-neon.ipk under oe-core/build/tmp-eglibc/deploy/ipk/cortexa9hf-vfp-neon Jan 10 06:20:51 my question is how can i make libstdc++6.so in my rootfs? Jan 10 06:22:50 i add libstdc++6 in my CORE_IMAGE_EXTRA_INSTALL , but it say ERROR: Nothing RPROVIDES 'libstdc++6' Jan 10 09:00:00 sss: i think virtual/libc should work Jan 10 09:24:19 morning all Jan 10 09:45:22 autofs recipe in meta-networking layer is creating problem Jan 10 09:45:36 it is being inherited from systemd Jan 10 09:46:07 so this layer will not work alone one need to have meta-systemd layer as well in its build Jan 10 09:46:13 is there a fix for that? Jan 10 09:46:46 there is bbappend in meta-systemd Jan 10 09:47:04 so there shouldn't be systemd interited in main recipe, just in bbappend Jan 10 09:47:33 (re)move it and send patch to oe-devel ML Jan 10 09:48:32 OK ... just wanna make sure that removing it is the solution ..... thanks Jan 10 09:48:34 send a patch Jan 10 09:50:31 JaMa|Off: I can't see bbappend for autofs in meta-systemd/meta-networking/ Jan 10 09:50:52 rather there is no folder for autofs Jan 10 09:51:50 I think I need to seed bbappend of autofs for meta-systemd/meta-networking as well Jan 10 09:54:35 Noor: ah it was in atftp not autofs Jan 10 09:54:59 but still move inherit and SYSTEMD_* settings to bbappend Jan 10 09:55:35 JaMa|Off: sure Jan 10 10:31:53 hi bluelightning Jan 10 10:34:44 I use in my recipe SRCREV = "${AUTOREV}" PV = "0.0+gitr${SRCREV}", but so th packet generated has the name like 0.0+gitrAUTOINC Jan 10 10:35:16 use SRCPV Jan 10 10:35:17 can I use PV = "0.0+gitr${SRCPV}" or it is deprecated? Jan 10 10:35:52 silvio: are you sure AUTOINC is in package name and version or do you see it only in bitbake log? Jan 10 10:36:10 it gets replaced with number later Jan 10 10:37:44 JaMa|Off, the ipk generated has AUTOINC in the name, like this: pluto_0.0+gitrAUTOINC-0.3.2_armv7a-vfp.ipk Jan 10 10:38:03 ok that's bad Jan 10 10:38:07 is PR service running? Jan 10 10:38:24 but it should use at least 0 Jan 10 10:38:51 and I prefer see the git sha, how to check PR running? Jan 10 10:39:09 you have to explicitly enable it Jan 10 10:40:08 I set in the recipe PR = "0.3.3", is sufficient? Jan 10 10:40:33 *PR = "0.3.2" Jan 10 10:41:29 silvio: no https://wiki.yoctoproject.org/wiki/PR_Service Jan 10 10:41:39 JaMa|Off, thanks Jan 10 10:41:45 silvio: or just revert that bitbake change like I did https://bugzilla.yoctoproject.org/show_bug.cgi?id=3071 Jan 10 10:42:31 ERROR: ParseError at /home/hrw/HDD/devel/canonical/aarch64/openembedded/repos/meta-openembedded/meta-networking/recipes-daemons/autofs/autofs_5.0.7.bb:8: Could not inherit file classes/systemd.bbclass Jan 10 10:42:35 normal? Jan 10 10:42:42 morning all Jan 10 10:42:58 hrw: Noor already working on it Jan 10 10:43:20 yeah about to send a patch Jan 10 10:43:24 ok Jan 10 10:43:26 hi hrw Jan 10 10:43:33 in meantime I dropped systemd inherit Jan 10 10:43:57 layer.conf of systemd layer scared me off ;D Jan 10 10:44:01 :) Jan 10 11:04:41 the git fetcher has this option: Jan 10 11:04:47 - rebaseable Jan 10 11:04:51 rebaseable indicates that the uptream git repo may rebase in the future, and current revision may disappear from upstream repo Jan 10 11:05:13 how can a rebase remove a revision from a repository? Jan 10 11:05:35 err Jan 10 11:05:43 I mean to say, the git fetcher in bitbake Jan 10 11:06:47 why not? Jan 10 11:07:15 with push -f allowed you can do whatever you want with repo Jan 10 11:09:11 the logic described in the comment is not what you're saying Jan 10 11:09:11 the comment says "upstream rebase" therefore "current revision may disappear" Jan 10 11:09:42 the comment implies that a revision may disappear as a result of a rebase Jan 10 11:10:26 (not as a result of removing the revision) Jan 10 11:11:09 may disapper if you want it to disappear Jan 10 11:11:30 right Jan 10 11:11:39 but that's not the justification in the source Jan 10 11:11:45 so I don't see anything wrong in that comment Jan 10 11:12:10 < JaMa|Off> may disapper if you want it to disappear Jan 10 11:12:15 that isn't what the comment says Jan 10 11:12:45 and? so it may disapper it's still true Jan 10 11:13:30 fetcher cannot know what will happen in upstream repo Jan 10 11:13:51 the comment implies that the disappearance is a consequence of upstream rebasing Jan 10 11:14:05 is possible consequence Jan 10 11:14:11 how? Jan 10 11:14:42 how does a rebase operation imply the possible disappearance of a revision? Jan 10 11:15:04 rebase -i, git-filter-branch, git push Jan 10 11:15:53 that's more than just a rebase operation Jan 10 11:16:08 you've included "git-filter-branch" Jan 10 11:39:58 JaMa|Off, now Pr server is not running , but it is start at every bitbake istance? Jan 10 11:40:36 read wiki and oe-core ML Jan 10 11:49:13 JaMa|Off: can a rebase operation by itself result in the orphaning of revisions? Jan 10 12:02:47 i got a issue with bbappend mechnism Jan 10 12:03:14 i placed a .bbappend in my layer where i add SRC_URI += "file://my.patch" Jan 10 12:03:35 and i added a directory with the package name and placed the patch file there Jan 10 12:03:51 still doesnt find the file and trys to download it from a mirror Jan 10 12:03:54 any hints ? Jan 10 12:08:31 seems it is not in default path Jan 10 12:09:37 probably you can just put it under /files in your recipe dir but check FILESEXTRAPATHS Jan 10 12:10:10 hmm i tryied /files also Jan 10 12:10:27 i must have screwd something else here Jan 10 12:11:27 how would i enbale more debug in order to see where he looks for ? Jan 10 12:14:17 rob_w: add FILESEXTRAPATHS, see other bbappends for examples Jan 10 12:14:29 rob_w: FILESPATH in bitbake -e output will help you debug it Jan 10 12:17:01 thx Jan 10 12:17:26 our rpjday put all together here: http://www.crashcourse.ca/wiki/index.php/FILESEXTRAPATHS_and_bbappend_files Jan 10 12:18:14 (with his thoughts :) Jan 10 12:18:44 nice Jan 10 16:05:23 JaMa|Off: ERROR: ParseError at /home/otavio/hacking/fsl-community-bsp/sources/meta-openembedded/meta-networking/recipes-daemons/autofs/autofs_5.0.7.bb:8: Could not inherit file classes/systemd.bbclass Jan 10 16:06:09 otavio: that was fixed in the morning Jan 10 16:33:14 OE lacks python dependencies generator ;( Jan 10 16:33:24 mickeyl where are you... Jan 10 16:38:26 hrw: do you mean this? openembedded-core/scripts/contrib/python/generate-manifest-2.7.py Jan 10 16:41:33 i'd assume he means generation of rdepends based on imports Jan 10 16:41:39 the way we do for perl (iirc) and kernel modules and the like Jan 10 16:43:08 mickeyl si done with oe Jan 10 16:44:38 hm the idention messages are useless Jan 10 16:45:48 Failure expanding variable populate_packages Jan 10 16:45:56 what is it Jan 10 16:46:01 post_somehting script? Jan 10 16:46:10 marvin_the_roboter Jan 10 16:46:12 or what Jan 10 16:47:21 JaMa|Off: thats only for python not extensions Jan 10 16:47:49 JaMa|Off: I did python-numpy 1.7.0rc1 update and to test it I had to rebuild rootfs and packages 3 times to get all deps Jan 10 16:48:04 and now I do not find the policy Jan 10 16:48:14 was it python tabs or shell Jan 10 16:49:36 python's spaces, shell is tabs Jan 10 16:49:38 * kergoth mutters Jan 10 16:49:52 eh. I have all deps but python does not finds nose Jan 10 16:50:15 thanks kergoth Jan 10 16:50:22 do we have a wiki side? Jan 10 16:50:31 stupid wiki search did not find something Jan 10 16:52:05 woglinde: search for OE styleguide Jan 10 16:53:16 jama okay whats wrong when I get -> " Failure expanding variable populate_packages" Jan 10 16:53:58 ok, someone remembers how does python extensions installing works in OE? Jan 10 16:54:38 python-nose.bb inherits distutils, package is created, files are in /usr/lib/python2.7/site-packages/nose-1.2.1-py2.7.egg/nose/ Jan 10 16:54:58 echo "import nose" | python == ImportError: No module named nose Jan 10 16:56:20 ok, symlink /usr/lib/python2.7/site-packages/nose-1.2.1-py2.7.egg/nose/ -> /usr/lib/python2.7/nose works Jan 10 16:57:35 and again... another missing python... Jan 10 16:57:38 ARGH Jan 10 17:05:50 hm okay packages split Jan 10 17:43:08 uf. started tests. Jan 10 17:43:15 new set of modules to add ;( Jan 10 17:43:26 ERROR: Nothing RPROVIDES 'python-gzip' (but /home/hrw/HDD/devel/canonical/aarch64/openembedded/repos/meta-openembedded/meta-oe/recipes-devtools/python/python-numpy_1.7.0.bb RDEPENDS on or otherwise requires it) Jan 10 17:43:30 ;( Jan 10 17:44:21 s/gzip/zlib and do Jan 10 19:06:15 do you know anyone working in musl support for oe-core? Jan 10 19:26:39 hi, what is the reason for having meta-* in .gitignore in openembedded-core's repo ? Jan 10 19:26:40 log says "meta-XYZ directories have been manually added in the past, instead always ignore them unless they are explicitly added" (3c6e85c653ce176fd2cb5a570e63c8e5da5a4e48) : does anyone remember why this was needed ? Jan 10 19:28:41 i'd guess to prevent people using a poky-style-layout from accidentally committing one of their repositories, but that's a guess Jan 10 19:42:11 nothing beats native build done on slow emulated only architecture ;D Jan 10 19:42:57 hi Saul Jan 10 19:45:59 kergoth: ok thanks. The drawback is that's also filtering meta-*bb Jan 10 19:47:04 kergoth: of simply doing meta-*/ fix the problem Jan 10 20:29:03 hm can I store own licenses file easily in my own layer? Jan 10 20:54:21 hi woglinde , you mean like in meta/files/common-licenses ? Jan 10 20:55:52 yes Jan 10 20:56:04 or do they need all to go core Jan 10 20:56:12 hm better I am asking on the ml Jan 10 20:56:56 woglinde: I don't know, yes ask on the ML that's an interesting question Jan 10 21:16:19 woglinde: you can store in your layer if they are complementary to whats provided in OE-Core Jan 10 21:16:37 woglinde: but oe-core would not mind getting them in its pile Jan 10 21:17:08 only thing would be to verify the licenses are SPDX form etc. Jan 10 21:17:39 I have bunch of licenses in my own layer which are only pertaining to recipes in my layer Jan 10 21:31:23 khem ah okay Jan 10 21:38:43 hi :) **** ENDING LOGGING AT Fri Jan 11 02:59:58 2013