**** BEGIN LOGGING AT Wed Aug 13 02:59:58 2014 Aug 13 07:23:42 * mranostay taps mic Aug 13 07:26:04 morning all Aug 13 07:33:57 bluelightning: how blue is the lightning this morning? Aug 13 07:34:21 mranostay: it's sunny out, so not all that much :) Aug 13 07:34:41 bluelightning: where are you again? Aug 13 07:34:44 UK? Aug 13 07:35:01 * LetoThe2nd certainly can't confirm neither blue nor lightning nor sunny. Aug 13 07:35:04 just *rain* Aug 13 07:35:24 well, if that helps you... it's raining in Nice, France ;-( Aug 13 07:35:51 ndec: i like to annoy you french people by saying Nice in english :) Aug 13 07:36:30 hehe... Aug 13 07:36:42 mranostay: yes, London Aug 13 07:36:46 ndec: funny, cousin of mine just sent me a postcard from nice Aug 13 07:37:26 LetoThe2nd: I bet it was not raining on the postcard.. Aug 13 07:37:39 ndec: you're guessing right Aug 13 07:37:50 you have to cover your mail before dropping in the box Aug 13 07:38:11 but what is rain really? even portland isn't that rainly :) Aug 13 07:38:15 *rainy Aug 13 08:23:31 Hello, I am using bitbake to customize my rootfs (the whole distribution was initialy provided by EUKREA). I don't where to search good packages to have PULSEAUDIO completely installed. I have no pulse directory or bin in the new rootfs (already customised with cronie, logrotate, gstream, tzdata). This is same problem as in the mailing list : https://lists.yoctoproject.org/pipermail/yocto/2013-September/016119.html Should I rea Aug 13 08:33:45 I have also more basic question, any chance to have help ? Aug 13 08:34:43 just ask, someone will come and help you.. Aug 13 08:35:56 Vincent_DIEHCO: do you have some package manager on your rootfs? Aug 13 08:36:57 Vincent_DIEHCO: btw, your post was truncated here: Should I rea... Aug 13 08:37:51 lpapp : Should I reactivate the thread to know the issue ? Aug 13 08:38:26 lpapp : I think I have not package manager in my rootfs Aug 13 08:39:04 Vincent_DIEHCO: so what does bitbake -e | grep ^DISTRO_FEATURES say? Aug 13 08:42:01 lpapp : DISTRO_FEATURES="alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl libc-libm libc-libm-big libc-locales libc-locale-code Aug 13 08:42:19 lpapp : libc-memusage libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc libc-posix-wchar-io pulseaudio sysvinit" Aug 13 08:44:21 lpapp : I only add "pulseaudio" package in my recipe Aug 13 08:58:47 Something I do not understand in my recipe : I have "alsa-utils-aplay" instead of only "alsa-utils" in my mind (same think with "gst-plugins-base-volume" and "gst-plugins-base" I added). So for a package as "pulseaudio" how to know if there are "dependancies" to explicit ? or the ones optionals ? Aug 13 09:26:58 lpapp: It seems there was already "pulseaudio" in DISTRO_FEATURES list before adding pulseaudio in my recipe. Aug 13 09:41:22 <[Sno]> I build my image with DISTRO_LIBC_FEATURES = "... libc-locales libc-locale-code ..." and ENABLE_BINARY_LOCALE_GENERATION=1 Aug 13 09:44:03 <[Sno]> I find several libc/localedata/de_DE* below eglibc-locale and some *.po files etc. Aug 13 09:44:37 <[Sno]> however - I do not find any of them below tmp/sysroots/ nor on final image Aug 13 09:44:59 <[Sno]> what do I have to specify to add locales to my generated image? Aug 13 09:49:58 [Sno]: have you checked this: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_LINGUAS Aug 13 09:53:17 <[Sno]> ndec: is there a way to install "all"? Aug 13 09:53:41 <[Sno]> I understood IMAGE_LINGUAS that it restricts to named ones Aug 13 09:55:34 i don't think you can request 'all' Aug 13 09:55:57 [Sno]: based on image.bbclass, no. Aug 13 09:56:26 (but it would probably be an easy patch to extend it with some python skill) Aug 13 09:56:28 <[Sno]> can I somehow force utf8? Aug 13 09:56:50 <[Sno]> lpapp: I check that after current sprint (put an item on backlog ^^) Aug 13 09:57:50 [Sno]: GLIBC_GENERATE_LOCALES? Aug 13 09:58:23 from the local.conf sample: #GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8" Aug 13 09:58:23 #IMAGE_LINGUAS ?= "en-gb" Aug 13 09:59:35 <[Sno]> lpapp: GLIBC_GENERATE_LOCALES looks really be a filter - but I give it a try, thanks (will take some time to bitbake the image) Aug 13 10:00:07 it is strange that it is not documented though in the YRM. Aug 13 10:00:30 <[Sno]> likely they welcome patches :D Aug 13 10:00:51 [Sno]: yeah, I am reporting it, btw, you can supply "all" to that one. Aug 13 10:01:01 <[Sno]> cool, thanks Aug 13 10:06:53 [Sno]: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6629 Aug 13 10:06:55 Bug 6629: normal, Undecided, ---, scott.m.rifenbark, NEW , Document GLIBC_GENERATE_LOCALES Aug 13 10:11:44 <[Sno]> lpapp: from python code of IMAGE_LINGUAS it probably accepts "*" :) Aug 13 10:11:52 <[Sno]> checking that >:-) Aug 13 10:15:09 [Sno]: I wonder how you thought that... Aug 13 10:17:26 RDEPENDS accepts wildcard, you mean? Aug 13 10:18:21 <[Sno]> lpapp: simply add IMAGE_LINGUAS="*" to local.conf - the image.bbclass uses locale-base-%s split(getvar(IMAGE_LINGUAS)) Aug 13 10:19:08 yeah, I am not asking about that part, I can read python code OK :) Aug 13 10:19:18 <[Sno]> OK :) Aug 13 10:19:23 hello :) Aug 13 10:19:41 I thought RDEPENDS does not accept wildcard, but I am probably wrong then. Aug 13 10:19:46 Does anyone know if there are somewhere qt-gstreamer recipes available? I couldn't find it :( Aug 13 10:19:58 for gstreamer 1.0 if possible Aug 13 10:22:06 <[Sno]> lpapp: there're some eg. en-gb* ipk's - but maybe I understand something wrong here Aug 13 10:25:17 ivanstojanovic: hmm, close, but not cugar, I guess. Can you hack it yourself together? Aug 13 10:25:20 cigar* Aug 13 10:35:00 <[Sno]> lpapp: you're right - no package matching locale-base-* :) Aug 13 11:02:11 [Sno]: I think it would be nice to have "all" like for the other variable. Not that I would use it on real embedded, but it can be OK for more powerful embedded. Aug 13 11:52:16 Hello, why the yocto Packages Report System (see http://packages.yoctoproject.org/) does not show result for "gst-plugins-good-wavparse" although this package is recognized in a bitbake recipe ? I am still looking for installing pulseaudio completely, I don't know how to have pulse or pulseaudio directory / bin in the rootfs. Aug 13 11:58:47 Vincent_DIEHCO: have you checked if you have any package manager on the board? Aug 13 11:58:57 Or you would like to generate pulse as part of the rootfs only? Aug 13 12:00:35 Vincent_DIEHCO: you can check the package manager e.g. with bitbake -e | grep ^PACKAGE_CLASSES Aug 13 12:02:36 you can also look for package-management in IMAGE_FEATURES Aug 13 12:02:52 lpapp : result is PACKAGE_CLASSES="package_ipk" I used to build rootfs when I add a functionnality. Aug 13 12:04:11 Vincent_DIEHCO: bitbake -e | grep ^IMAGES_FEATURE | grep "package-management" -> is that also there? Aug 13 12:04:25 Vincent_DIEHCO: have you checked whether the pulseaudio package was built? Aug 13 12:04:35 IMAGE_FEATURES="${EXTRA_IMAGE_FEATURES}" vincent@electronic:~/oe_dir3/setup-scripts$ echo ${EXTRA_IMAGE_FEATURES} vincent@electronic:~/oe_dir3/setup-scripts$ Aug 13 12:10:09 lpapp : I have some pulseaudio directories in my bitbake directory ./build/tmp-defaultsetup-eglibc-eglibc/... I don't know how to check in the rootfs. Aug 13 12:11:45 Check ./build/tmp/work/foo/pulseaudio Aug 13 12:11:59 to find out what packages are produced by a recipe, the easiest thing is to look under packages-split under the workdir for the recipe Aug 13 12:12:46 if you're not sure where the workdir is you can find out by running bitbake -e recipename | grep ^WORKDIR= Aug 13 12:15:06 is there any bugreport to finally have an option for searching? bitbake -e recipename | grep ^WORKDIR= => bitbake -s WORKDIR? Aug 13 12:15:14 I had the same issue more than a year ago, too :-) Aug 13 12:15:56 bitbake --search stuff Aug 13 12:19:19 bitbake -e pulseaudio | grep ^WORKDIR WORKDIR="/home/vincent/oe_dir3/setup-scripts/build/tmp-defaultsetup-eglibc-eglibc/work/armv5te-oe-linux-gnueabi/pulseaudio/3.0-r0" Does it mean pulseaudio is built ? Aug 13 12:19:24 lpapp: it's something that's pretty much already captured as part of kergoth's "bb" external tool; how we can integrate that properly has still not been determined Aug 13 12:20:08 Vincent_DIEHCO: not necessarily, no; but if that directory does exist then it likely has been Aug 13 12:20:33 Vincent_DIEHCO: well, find /home/vincent/oe_dir3/setup-scripts/build/tmp-defaultsetup-eglibc-eglibc/work/armv5te-oe-linux-gnueabi/pulseaudio/3.0-r0 -name pulseaudio Aug 13 12:21:02 (or whatever you are trying to get in the end) Aug 13 12:21:25 if it is built, then check whether it is put into package-split as suggested, if it is there, then check the image, etc. Aug 13 12:23:04 bluelightning: cli tool ? Aug 13 12:38:08 lpapp : I have pulseaudio in pkgdata packages-split package (I think I do not have to upgrade my kernell 2.6.37 to have pulseaudio that's right ?) Aug 13 12:38:43 Vincent_DIEHCO: well, it depends ... Aug 13 12:45:06 Vincent_DIEHCO: beside pkgdata, there must be an image subdirectory, too. Aug 13 12:46:50 lpapp : yes :./pkgdata/pulseaudio ./pkgdata/runtime/pulseaudio ./pkgdata/runtime-reverse/pulseaudio Aug 13 12:47:13 Vincent_DIEHCO: what is in packages-split ? Aug 13 12:47:23 what subdirectories, that is Aug 13 12:48:05 vincent@electronic:~/oe_dir3/setup-scripts/build/tmp-defaultsetup-eglibc-eglibc/work/armv5te-oe-linux-gnueabi/pulseaudio/3.0-r0$ find . -name pulseaudio Aug 13 12:48:18 ./packages-split/pulseaudio ./packages-split/pulseaudio-module-bluetooth-proximity/usr/lib/pulseaudio ./packages-split/libpulsecommon/usr/lib/pulseaudio ./packages-split/pulseaudio-dbg/usr/bin/.debug/pulseaudio ./packages-split/pulseaudio-dbg/usr/src/debug/pulseaudio ./packages-split/pulseaudio-dbg/usr/lib/pulseaudio ./packages-split/pulseaudio-module-alsa-card/usr/share/pulseaudio ./packages-split/pulseaudio-misc/usr/lib/pulse Aug 13 12:48:32 ./packages-split/pulseaudio-module-gconf/usr/lib/pulseaudio ./packages-split/pulseaudio-dev/usr/lib/pulseaudio ./packages-split/pulseaudio-server/usr/bin/pulseaudio Aug 13 12:50:01 Vincent_DIEHCO: you did not check the image directory. Aug 13 12:50:14 also whether the package-split directories contain what the need to. Aug 13 12:50:51 there are also results in ./package Aug 13 12:52:37 ./package/usr/bin/pulseaudio ./package/usr/bin/.debug/pulseaudio ./package/usr/src/debug/pulseaudio ./package/usr/lib/pulseaudio ./package/usr/share/pulseaudio Aug 13 12:53:14 I am looking for the image directory path with the reference man Aug 13 12:58:34 Vincent_DIEHCO: what have you done to 'add' pulseaudio in your image? enabling the DISTRO_FEATURE isn't enough, you need to add the packages to the image. Aug 13 12:59:18 i am not using pulse, but looking at the recipe, it seems that the binary package to add into the image is pulseaudio-server, which you should see in packages-split as indicated above Aug 13 12:59:45 ok, I give you some more explanation of my tool chain Aug 13 13:01:09 rootfs result is in build/tmp-defaultsetup-eglibc-eglibc/deploy/images/eukrea-cpuimx25, to had packages I edited ./sources/meta-eukrea/recipes-eukrea/images/eukrea-base-image.bb Aug 13 13:01:33 I never change the kernel Aug 13 13:01:50 what change did you make in the image? Aug 13 13:02:06 you don't need to change the kernel. Aug 13 13:03:17 ndec : I add names of packages in IMAGE_INSTALL Aug 13 13:04:43 ndec : I did for libxml2 freetype cronie logrotate tzdata gstreamer & cie and now for pulseaudio Aug 13 13:05:10 as i said, you should add pulseaudio-server Aug 13 13:05:48 you can inspect what each 'binary' package contain by looking at WORKDIR/packages-split, or possibly looking at tmp/deploy/ipk/... Aug 13 13:06:30 bitbake does not accept pulseaudio-server Aug 13 13:07:21 you mean as of 'bitbake pulseaudio-server'? Aug 13 13:08:47 Vincent_DIEHCO: you do not have anything in DISTRO_FEATURES_BACKFILL_CONSIDERED either, right? Aug 13 13:09:52 FFS, it is not the poky build system! Aug 13 13:09:54 http://events.linuxfoundation.org/events/embedded-linux-conference-europe/extend-the-experience/yocto-dev-day Aug 13 13:11:30 hehe Aug 13 13:12:29 ndec : if I add pulseaudio-server after pulseaudio and others packages in the recipe, I have the error : Collected errors: | * satisfy_dependencies_for: Cannot satisfy the following dependencies for pulseaudio-server: | * consolekit * | * opkg_install_cmd: Cannot install package pulseaudio-server. | ERROR: Function failed: do_rootfs Aug 13 13:12:58 I am cranky again this morning Aug 13 13:13:06 which is the correct sysroot that is also put into the image? I am trying to use build/tmp/sysrootfs/foo, but apparently, it is not it. Aug 13 13:13:13 Vincent_DIEHCO: hmm. ok. which version of OE are you using? i should have started with that. Aug 13 13:13:32 lpapp: the sysroot is not put into the image Aug 13 13:14:25 ndec: I know, but I am looking for exactly the same rootfs Aug 13 13:14:34 since gdb (client) and gdbserver need to work on the same. Aug 13 13:14:34 lpapp : DISTRO_FEATURES_BACKFILL="pulseaudio sysvinit" Aug 13 13:14:35 ah. that's different then ;-) Aug 13 13:14:43 it's in the image WORKDIR/rootfs Aug 13 13:14:48 Vincent_DIEHCO: there ya ho. Aug 13 13:15:35 Vincent_DIEHCO: anyway, if you had already added the pulse packages to the image, I have no clue... Aug 13 13:15:46 Vincent_DIEHCO: check what packages the image tries to reuse for the generation. Aug 13 13:16:37 Vincent_DIEHCO: the usual bitbake -e ... | grep ^IMAGE_INSTALL Aug 13 13:17:25 you can also check the manifest file ("${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest). Aug 13 13:17:43 ndec: different?! Why are there different rootfses generated?! Aug 13 13:18:14 one is the rootfs, the other one is the sysroot that contains development files for the build Aug 13 13:18:43 ndec: so why would they contain e.g. different libc versions? Aug 13 13:19:56 hmm. what do you mean? Aug 13 13:20:02 lpapp : Do you mean one package name appears in two recipe ? Aug 13 13:20:53 ndec: what I am seeing is that using the aforementioned sysroots for gdb on the host with the rootfs on the target and gdbserver, gdb seems to think that some core libraries are different. Aug 13 13:20:59 hence, it cannot properly debug stuff. Aug 13 13:33:51 ndec: I honestly do not see rootfs in build/tmp/work/ Aug 13 13:37:01 ndec: see, what I need is to set up the _same_ rootfs on the host that is burnt onto the target. Aug 13 13:37:08 otherwise gdbserver + gdb will not work. Aug 13 13:40:28 lpapp: the same rootfs is in the image WORKDIR/rootfs, but it gets removed with rm_work. Aug 13 13:41:21 ndec: you mean in each package's chunk as zillion separate subdirectories? Aug 13 13:41:38 no, i mean the 'image' WORKDIR. Aug 13 13:41:54 the image is a recipe (.bb) itself. so it has its WORKDIR too Aug 13 13:41:57 I do not follow, really. Aug 13 13:42:04 can you give a concrete example? Aug 13 13:42:15 a concrete path where the _whole_ rootfs is available as sysroot? Aug 13 13:42:24 (otherwise gdb + gdbserver will not work) Aug 13 13:42:43 tmp-eglibc/work/ifc6410-oe-linux-gnueabi/core-image-minimal/1.0-r0/rootfs Aug 13 13:43:15 it's the folder where the 'rootfs' is built during do_rootfs before it gets compressed in DEPLOY Aug 13 13:43:40 ok, thanks. Aug 13 13:49:08 ndec: I am still wondering why gdb thought I would have different versions in the image and build/tmp/sysroots, but I guess it does not matter since I should not use build/tmp/sysroots... Aug 13 13:59:30 lpapp : I do not know what I am looking for but I understand there is problem of dependance. One tool included in pulseaudio-server named consolekit cannot be provided (I don't know why) . I think this is same problem for me discussed here http://lists.openembedded.org/pipermail/openembedded-core/2012-November/071168.html my OE version is Dylan. Aug 13 14:00:47 If it is same I think I can found a "work around" somewhere in doc or mailing list. Aug 13 14:12:21 why do I keep having "Multiple .bb files are due to be built which each provide virtual/libgles1" while I set PREFERRED_PROVIDER_virtual/libgles1 ? Aug 13 14:12:44 with the same error on ligles2 and egl Aug 13 14:13:07 Anarky: you've left out a virtual/ that something - likely mesa - is providig but you're not redefining Aug 13 14:14:25 rburton: ok, but what happens if I set this virtual/ to libgles-omap3 while it's not providing this virtual? Aug 13 14:19:07 I just tried to add virtual/libgl and virtual/mesa to libgles-omap3 (ie everything that mesa provides) but this error is still happening Aug 13 14:19:29 if gles-omap3 doesn't support something and you don't want mesa, set it to "" Aug 13 14:19:41 and if you're still getting the error then there's a virtual still unset Aug 13 14:19:51 feel free to pastebin your settings Aug 13 14:20:07 (surprised this is still a problem with the drivers) Aug 13 14:22:17 Anyone know how to use KERNEL_MODULE_PROBECONF? I cannot find any examples of how to use it in Poky or OE and there is nothing in the documentation... Aug 13 14:23:13 Hello. I have question that I need little help with. I am working with ARM board that has minimal yacto installed on it. I am creating packages with checkinstall (RPM). It all goes well so far. When I try to install such package I get warning message "warning: package postgresql-9.3.5-1.armv7l is intended for a armv7l-unknown-linux platform" Aug 13 14:23:34 I did created this rpm on this board. What is wrong? Aug 13 14:23:45 Saur: have you tried reading ./meta/classes/kernel-module-split.bbclass ? Aug 13 14:23:56 lpapp: Yes... Aug 13 14:24:02 Saur: read the kernel-module-split.bbclass it's relatively simple to understand Aug 13 14:24:07 uname -m shows armv7l. So looks like checkinstall detect it correct. Aug 13 14:24:48 Saur: for each module_conf_foo = "bar" line, you need to add "foo" in KERNEL_MODULE_PROBECONF variable Aug 13 14:25:05 Guma: I am not sure if it is due to unknown... tried to specify that in the build system? Aug 13 14:25:19 JaMa: Ok, so basically the same as with KERNEL_MODULE_AUTOLOAD. Aug 13 14:25:25 Saur: and "foo" is basename of the kernel module Aug 13 14:25:28 Saur: yes Aug 13 14:25:29 rburton: I'm surprised too, I add this error few weeks ago but the PREFERRED_PROVIDER worked; here are the relevant part: http://pastebin.com/2SYN7AbH Aug 13 14:25:51 Ok, should be simple enough to fix then. :) Aug 13 14:25:51 Saur: have you also read c56c9a2f41eac8f87f13547806edc794b77ba54e ? Aug 13 14:25:58 I found /etc/rpm/platform and it contents goes not have armv7l. Who creates and updates /etc/rpm/platform Aug 13 14:26:02 lpapp: Yes. :) Aug 13 14:26:07 http://lists.openembedded.org/pipermail/openembedded-core/2014-June/093436.html Aug 13 14:26:11 rburton: I tried to remove mesa-demos but it didn't changed anything Aug 13 14:26:19 Saur: you can also read e9cd8ba3dda624615b68c601eac04427d9483f14 and 6f8b5be646be0f3e15e215907547f11d2a23d81b in oe-core Aug 13 14:27:25 Anarky: huh, should work. at least that's what meta-intel does for emgd. Aug 13 14:27:33 * rburton kicks a build of meta-intel to see what happens Aug 13 14:27:43 lpapp: should ./configure auto detect it? Is it possible to add line to /etc/rpm/platform? Aug 13 14:28:03 Anarky: the other alternative is that something else is pulling in mesa directly Aug 13 14:28:45 e.g. weston used to do it before daisy Aug 13 14:28:45 rburton: ooh, virtual/libgl didn't take effect. i thought setting to "" would work. set it to mesa-gl Aug 13 14:29:17 Anarky: (you can tell the libgl preference didn't kick in as it warns that there are multiple providers to pick from) Aug 13 14:29:39 Guma: that's the other end of the process; /etc/rpm/platform is generated when the image is generated Aug 13 14:29:45 Anarky: then chase what is depending on virtual/libgl Aug 13 14:30:23 rburton: I saw that, if I don't write anything about libgl I don't get this note Aug 13 14:30:40 Anarky: because it defaults to mesa Aug 13 14:31:11 rburton: ok. How can I found with recipe is asking mesa? Aug 13 14:31:25 Anarky: git grep virtual/libgl should do it Aug 13 14:31:29 bluelightning: image? rpm image? or kernel image? or when image is installed (rpm) just to be clear Aug 13 14:31:44 Guma: the rootfs image Aug 13 14:32:11 bluelightning: I see. Thank you Aug 13 14:32:57 I think you may be able to add additional ones by adding them to PACKAGE_EXTRA_ARCHS Aug 13 14:34:02 bluelightning: so do you have idea how to fix it? looks like checkinstall uses uname -m to detect arch to create and package rpm. And this RPM does not want install on system what was created. How to fix this? or what to change? Suggestions? Aug 13 14:34:55 Guma: well, to be perfectly honest I wouldn't create packages in this manner, I'd use the build system Aug 13 14:35:21 Guma: but if you must do it this way then you probably just need to ensure that extra architecture gets added to PACKAGE_EXTRA_ARCHS Aug 13 14:36:57 bluelightning: "I'd use the build system" what build system are you referring? rpmbuild? Or some other tool? Aug 13 14:37:42 hi guys, I am still trying to get the qtgstreamer recipe working...but it's tricky :( I couldn't find nothing on the internet but for the old one 0.1, I am working with 1.x. Suggestions are welcome :) Aug 13 14:38:23 Guma: as in BitBake / OpenEmbedded, i.e. what the Yocto Project uses Aug 13 14:38:40 ivanstojanovic: show what you have already and what the error is. Aug 13 14:38:56 bluelightning: you manage to not use the work 'poky' ;-) Aug 13 14:39:27 ndec: 's poky ? Aug 13 14:39:36 ndec: bluelightning is a master of terminology, level 3 Aug 13 14:39:38 ndec: poky is just a reference of that ;) Aug 13 14:39:39 the 'word' Aug 13 14:40:02 terminology and politics, i guess ;-) Aug 13 14:43:25 here is the recipe: http://pastebin.ca/2832223 Aug 13 14:44:34 ivanstojanovic: 16-27 -> is that boilerplate really needed? Aug 13 14:46:21 @lpapp: no clue what bolierplate is :) Aug 13 14:47:04 ivanstojanovic: it should be qt-gstreamer, not qtgstreamer, to match the upstream name. but that's a detail for now.. Aug 13 14:47:30 ivanstojanovic: what happens for bitbake? Aug 13 14:47:35 that should not be a problem I think, but I will rename it immediately anyhow Aug 13 14:47:42 12-14 also looks boilerplate. Aug 13 14:47:54 in addition, why inherit both qmake5 and cmake? Aug 13 14:47:58 They are different build systems, no? Aug 13 14:49:06 I added a comment (the error message after I try to bake it) Aug 13 14:50:06 bluelightning: I will look into BitBake later. for now I will stay with checkinstall/rpmbuild. I just did quick grep and I can't find PACKAGE_EXTRA_ARCHS in source configure or checkinstall script. Are you refering using --arch switch in checkinstall? Aug 13 14:50:07 why both, I used a template I found on the internet for qt-gstreamer 0.1...it was like that there so I didn't change it Aug 13 14:50:55 Guma: sorry, I am talking about what you'd need to set when using our build system to actually build the image Aug 13 14:50:58 rburton: thanks for the git grep, but the only thing defining with a ?= "mesa" is qemu Aug 13 14:51:05 ivanstojanovic: it seems to be a cmake based project, so I would not inherit qmake. Aug 13 14:51:11 Guma: in your case you could just edit /etc/rpm/platform I guess Aug 13 14:51:33 but when you refering to image you mean rootfs Aug 13 14:51:49 Guma: yes Aug 13 14:53:56 bluelightning: so PACKAGE_EXTRA_ARCHS would have to be set in my case to armv7l? Aug 13 14:53:59 @lpapp: ok, I removed qmake5, it seems it still works Aug 13 14:54:24 @lpapp: I mean, it still doesn't work :) Aug 13 14:54:25 I did not build it yet. I took over someone else who is not here. So I am getting my feet wet. Aug 13 14:55:15 RPM packages have an embedded canonical arch assigned to them.. Aug 13 14:55:39 RPM 4 uses the 'arch' field from (essentially) the filename.. this causes issues where you get hard coded lists, and have to make code changes to resolve them.. Aug 13 14:55:40 Guma: surely it would be the value that rpm is claiming is not understood - i.e. armv7l-unknown-linux Aug 13 14:55:58 RPM 5 instead uses the /etc/rpm/platform file to list what the core platform is, followed by a list of compatible canonical arches.. Aug 13 14:56:10 (the later list can included regex values) Aug 13 14:56:40 Guma: ^ fray_ is the expert on this area ;) Aug 13 14:56:40 ivanstojanovic: where can the error be seen? Aug 13 14:56:44 if you (on the target) use rpm -q --yaml and inspect the result you should find the arch info, such as armv7l-unknown-linux-gnueabi Aug 13 14:57:06 I don't remember the field offhand, and I don't have a bootable target at the moment to find the right value Aug 13 14:57:18 @lpapp: at the same link, in the comments: http://pastebin.ca/2832223 Aug 13 14:57:47 the /etc/rpm/platform list is ordered though.. if you have multiple packages (same name, different canonical arch, the highest in the order will be installed in the case of a conflict..) Aug 13 14:57:59 this allows the system to determine the "best" fit as well.. so order does matter Aug 13 15:00:49 ivanstojanovic: DEPENDS = "qtbase"? Aug 13 15:01:14 (and whatever else it depends on) Aug 13 15:01:54 @lpapp: that error has something to do with OE_QMAKE_PATH_EXTERNAL_HOST_BINS...there is an ugly hack in cmake recipe for that error...but let me check if DEPENDS = "qtbase" will change anything Aug 13 15:02:20 ivanstojanovic: well, if it does not, try to drop Yocto and get qt-gstreamer working manually with cmake. Aug 13 15:02:31 That would be the first step to see how it is buildsystem is supposed to work. Aug 13 15:02:36 its* Aug 13 15:03:24 @lpapp: ok, let's see how that will work Aug 13 15:03:36 @lpapp: thanks :) Aug 13 15:14:01 fray_: I am on RPM 5 Aug 13 15:17:18 fray_: rpm -q --yaml does not work since package is not installed. And installing I get this message "warning: package postgresql-9.3.5-1.armv7l is intended for a armv7l-unknown-linux platform" Aug 13 15:17:51 So should I for now add armv7l-unknown-linux platform to /etc/rpm/platform at the very bottom? Aug 13 15:19:10 And I am assuming the rebuilding rootfs (as bluelightning pointed out earlier) add PACKAGE_EXTRA_ARCHS="armv7l" ? So it will show up in packages? Aug 13 15:19:15 Is that how this works? Aug 13 15:19:44 rpm -qp --yaml Aug 13 15:19:47 add the 'p' for package Aug 13 15:20:38 ya, if you are getting that message the internal arch is likely armv7l-unknown-linux if you add that it should allow the install.. Aug 13 15:20:57 As for the PACKAGE_EXTRA_ARCHS, you'd have to add it as an "_append" Aug 13 15:21:24 I'd be careful though.. AFAIK none of that is Yocto Project naming.. so the package may not be compatible with your system Aug 13 15:22:57 I just quickly added armv7l-.*-linux.* to platform and warning is gone. I got another error about error: Failed dependencies: /proc/9626 is needed by postgresql-9.3.5-1.armv7l. But I think I know what that might be. One thig at a time Aug 13 15:23:06 let me try rpm -qp Aug 13 15:25:11 fray_: I see this "Arch: armv7l" Aug 13 15:25:50 thats not the right field.. look further for something like canonical arch Aug 13 15:25:58 (I'll see if I can find the name of the right field) Aug 13 15:26:37 'Arch:' is the unused filename architecture.. it's ignored by RPM5, as it's not explicit enough for the platform checking Aug 13 15:28:45 the value is 'Platform: Aug 13 15:28:50 i.e.: Platform: lib32_x86-windriver-linux-gnu Aug 13 15:29:22 you can query it directly as: Aug 13 15:29:23 fray_: Platform is armv7l-poky-linux-gnueabi Aug 13 15:29:25 ./rpm -qp --qf '%{NAME} %{PLATFORM}\n' Aug 13 15:29:46 there ya go.. thats the entry you need (or a wild card to match) in your /etc/rpm/platform file Aug 13 15:30:49 So I added armv7l-.*-linux.*. Should I change it to armv7l-poky-linux.* Aug 13 15:32:26 I already have arm-poky-linux-gnueabi in platform file. I will add armv7l-poky-linux-gnueabi right under it. Aug 13 15:33:13 yes.. Aug 13 15:33:17 typical file is: Aug 13 15:33:37 --[-] Aug 13 15:33:41 regex1 Aug 13 15:33:42 regex2 Aug 13 15:33:44 regex3 Aug 13 15:33:45 ... Aug 13 15:33:49 regexN Aug 13 15:34:09 (You've also found the format of the regex) ;) Aug 13 15:34:25 Yey!!! Aug 13 15:37:14 ok so co correct it in next rootfs build. Should I add PACKAGE_EXTRA_ARCHS="armv7l". that correct format for BitBake? Aug 13 15:45:17 fray_: Thank you for you help :) Aug 13 15:45:29 And bluelightning :) Aug 13 15:55:47 fray_: When looking in at my package internals "rpm -pq --yaml postgresql-9.3.5-1.armv7l.rpm | grep -i 9626" I see two entries. The reason I did this is that when trying to install "rpm -Uvh postgresql-9.3.5-1.armv7l.rpm" I get this error message: Aug 13 15:56:03 "/proc/9626 is needed by postgresql-9.3.5-1.armv7l" Aug 13 15:56:30 that sounds like a bug in the package! Aug 13 15:56:56 somehow something in the package got a link or otherwise reference to /proc/9626, which simply won't exist for you.. Aug 13 15:57:07 so you'll have to find and fix the package bug first.. Aug 13 15:57:31 there is per-file depednency information in most RPM packages.. you can query things like rpm -qp --filerequires and see if you can trace down what is requiring that and fix it Aug 13 15:57:43 I think it would be checkinstall / installwatch :) Aug 13 16:12:04 fray_: :) Is see /proc/self in it Aug 13 16:14:44 ya.. that is wrong Aug 13 16:14:55 package should never own or depend (directly) on proc self Aug 13 17:16:03 where would I suggest someone report a bug in meta-openembedded? Aug 13 17:26:29 openembedded-devel@lists.openembedded.org Aug 13 17:27:08 really? that's not just patches only? Aug 13 17:27:30 development discussion and patches Aug 13 17:30:56 ok thanks Aug 13 17:36:43 Anyone seen this or similar before? ERROR: The following packages could not be configured offline and rootfs is read-only: ttf-sazanami-mincho Aug 13 17:37:23 khem: I just discovered that we are getting some errors reported during eglibc configuration, might be related to your menu config patch (maybe) Aug 13 17:38:47 WarheadsSE: sounds like fontcache maybe? guess it thinks it needs to run on first boot on rw rootfs Aug 13 17:39:11 look and see what's in the postinst file Aug 13 17:39:19 hrm. A definitive WTF, because I have never once hit this before. Aug 13 17:39:33 me neither Aug 13 17:39:57 I've built this image recipe a lot of times, but today, wtfbbq Aug 13 17:40:49 did you update build branch? add a package with a new font dep? anything? Aug 13 17:40:57 fray: Not sure if I missed answer since I got disconnected. As far as PACKAGE_EXTRA_ARCHS="armv7l" goes is that the format I should use? Aug 13 17:43:50 Nothing that is related to anything to do with fonts, fontcache, etc. Aug 13 17:45:55 nerdboy: more over, wtf mate. This rootfs should not be in a RO state at the point it is doing the package configs. Aug 13 17:47:52 no, i think it means "is configured to boot ro" so it can't do it then either Aug 13 17:48:00 just a guess... Aug 13 17:48:50 pkg_postinst wants to run either offline (rootfs/image creation) or on first boot up Aug 13 17:49:44 * nerdboy pulling from memories of classic Aug 13 17:49:50 heh Aug 13 17:50:15 haven't really tried ro_rootfs with newer builds Aug 13 17:50:16 yes, it's failing postinst Aug 13 17:50:44 check with bitbake -e why your image is switcher to R-O and what try to re-execute the postinst by hand to see why it's failing Aug 13 17:50:55 often it's because of qemu-native not working correctly Aug 13 17:51:27 http://lists.openembedded.org/pipermail/openembedded-core/2014-July/095119.html Aug 13 17:52:23 hrm. Aug 13 17:53:03 def don't have this in my srcrevs for dora @ my manifest. Aug 13 17:54:41 it's not even in master, it's just example of possible issues I was hit by Aug 13 17:54:53 k, thanks for the heads up Aug 13 17:55:00 definitely *odd* Aug 13 17:55:07 in fontcache.bbclass as well as some other classes Aug 13 17:55:34 s/other classes/e.g. pango Aug 13 17:57:25 ah.. yup Aug 13 17:57:28 | > Executing update_font_cache Aug 13 17:57:30 | WARNING: intercept script "update_font_cache" failed, falling back to running postinstalls at first boot Aug 13 17:58:19 Considering we make squashfs images.. yeah, thats RO. Aug 13 18:01:11 hi nerdboy Aug 13 18:01:54 yo Aug 13 18:03:31 JaMa: nerdboy yup.. Aug 13 18:03:46 this one will be fun to hunt. Aug 13 18:06:26 it's not so complicated.. just re-run the postinst manually Aug 13 18:16:25 if all else fails, package the final cache... Aug 13 18:17:02 not the best option, but... Aug 13 18:19:47 WarheadsSE: gnar, that again. the log might be useful. what target machine? Aug 13 18:21:08 x64 making i586 Aug 13 18:21:19 no reason fontcache shouldn't be able to run with the right perms during normal postinst.. Aug 13 18:21:31 In Theory anyway... Aug 13 18:21:41 Yeah, never ever seen this before Aug 13 18:22:08 Even built a different image in this same build root, same state, no problem. Aug 13 18:22:51 i say that, but my rpi sato image is still contaminated with the wrong x-init package... Aug 13 18:26:23 WarheadsSE: does your recipe inherit fontcache, or have a hard-coded postinst script? Aug 13 18:26:53 * nerdboy never even looked at fontcache.bbclass before... Aug 13 18:28:08 We don't even have any custom font packages. Aug 13 18:28:52 looks like oe-core and poky/meta are different Aug 13 18:29:02 which one are you using? Aug 13 18:29:15 dora oe-core Aug 13 18:29:33 master poky/meta Aug 13 18:30:02 might be why i haven't seen it... Aug 13 18:52:15 * nerdboy still doing surgery on older kid's laptop Aug 13 18:53:43 with a whole week left before school starts Aug 13 21:46:10 sgw_: what error do you see Aug 13 21:47:37 Hi khem_, hang on I will pastebin it Aug 13 21:48:38 OK Aug 13 21:56:51 khem: had to rebuild, here's the output: http://pastebin.com/d9Ms96E8 Aug 13 22:03:43 khem it seems like it's not parseing the option-groups files correctly, just a guess Aug 13 22:20:11 So, I finally figured out a thing that's been bugging me for ages, which is that attempts to expand anything that uses TARGET_VENDOR for multilibs tend to fail. Aug 13 22:21:06 It turns out: There's a few things that happen early on (like preferred_ml_updates), which depend on TARGET_VENDOR, but TARGET_VENDOR_virtclass-multilib-foo doesn't get set until multilib_virtclass_handler_global, which doesn't execute until fairly late. Aug 13 22:21:23 But the TARGET_VENDOR values don't have any obvious reason to be contingent on a recipe being parsed. Aug 13 22:21:47 And this leads me to a thing I don't quite know about the order of events, which is: If I have two handlers for ConfigParsed, can I indicate in some way that one of them needs to happen first? Aug 13 22:22:16 nope. there's no way to enforce order. its possible the order *might* be reliable based on parse order / addhandler order, but i'm not certain Aug 13 22:22:37 oe-lite added inter-"hook" (event handler) dependencies ala addtask, but we don't have that (yet) Aug 13 22:23:12 So, the net result is: Nothing in a ConfigParsed handler can assume that TARGET_VENDOR_virtclass-multlib-foo will be set. Even if I move the setting for those into a separate handler to run on ConfigParsed. Hmm. Aug 13 22:24:12 the multilib class by definition isn't inherited until after the recipe itself is parsed Aug 13 22:24:26 Oh-hoh. Aug 13 22:24:30 I think I see the problem, then. Aug 13 22:24:42 Well, wait. This is multilib_global.bbclass. Aug 13 22:25:00 ah, right. well, keep in mind that ConfigParsed gets un-finalized metadata passed to it Aug 13 22:25:11 quite often a cnofigparsed handler will ahve to create a local copy and finalize it first to get appends/etc to apply Aug 13 22:25:18 Mostly, what it's doing is adding TARGET_VENDOR_virtclass-multlib-foo = "${TARGET_VENDOR}mlfoo", basically. Aug 13 22:25:26 Yeah. Aug 13 22:25:31 its a common pattern -- we need to fix that, make a finalized config metadata instance get passed around to folks that need it Aug 13 22:26:00 I had previously realized this was a problem, but I hadn't figured out *why* exactly, but it's killed otherwise-plausible designs before. Aug 13 22:26:15 The thing biting me right now: PREFERRED_VENDOR things using $TARGET_PREFIX don't get set correctly for multilibs. Aug 13 22:26:32 Because they get, e.g., i586-wrs-linux, instead of i586-wrsmllib32-linux. Aug 13 22:32:47 Come to think of it. Perhaps the right thing is to move the TARGET_VENDOR_* into a handler that runs on ConfigParsed, and ALSO move the preferred_ml_updates into that handler. Because that's more reasonably associated with multilib_global.bbclass than base.bbclass to begin with. Aug 13 22:42:31 Oh, hey, that worked. Aug 13 22:43:56 Okay, I think I have a proposed fix. In multilib_global.bbclass, add a new handler for ConfigParsed. Move the settings of TARGET_VENDOR_virtclass-multilib-* into that handler, and then have it call preferred_ml_updates(). Aug 13 22:44:01 Which is moved over there from base.bbclass. Aug 13 22:44:14 Net result, PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc then works. Aug 13 22:48:38 hi, I add this line"IMAGE_ROOTFS_EXTRA_SPACE = "512000" into local.conf then "bitbake core-image-full-cmdline", but there's no new .hddimg created with expected more 512MB space increated, deply/images Aug 13 22:49:01 how to force roots rebuild after loca.conf modified? Aug 13 22:51:40 EddyLaiTW: try doing a bitbake -c clean core-image-full-cmdline Aug 14 00:15:46 nerdboy: in hilarity, sure enough, same build root, right after that failure, turn around a build a more featured image? Wham, works. *facepalm* Go back to "problematic" one? Boom. Fail. *facedesk* Aug 14 00:17:07 better than it succeeding when you went back to the problematic one Aug 14 00:19:54 * nerdboy looks for a pillow... **** ENDING LOGGING AT Thu Aug 14 02:59:59 2014