**** BEGIN LOGGING AT Thu Sep 01 02:59:57 2011 Sep 01 08:21:43 I'm trying to add a project from OpenEmbedded and i'm running into issues with licencing Sep 01 08:22:26 The License is PD (Public Domain) and i have set this with LICENSE="PD" however the tar ball that the package downloads does not have a licence Sep 01 08:22:58 Which means I cannot specify a LIC_FILES_CKSUM Sep 01 08:31:10 Snafflehog: check if there is licensing header in some source files Sep 01 08:35:55 ok, i've managed to to find a lience and set beginning and end lines, but it says that it can't find the file Sep 01 08:36:21 I'm 100% which version it's downloading, where is the variable ${PV} set? Sep 01 08:36:33 Sorry, I'm NOT* 100% sure Sep 01 08:40:54 PV is set in recipe or taken from recipe filename (ie foo_1.0.bb -> PV=1.0) Sep 01 08:46:34 Snafflehog: if you don't have a license file you can point to ${COMMON_LICENSE_DIR}/PD Sep 01 08:46:49 it's not ideal but it will get you past the check Sep 01 08:49:05 bluelightning: perfect, that got it compiled, however what is the ${PV} variable and where is it set? Sep 01 08:49:27 Snafflehog: as JaMa said, PV is normally set automatically from the .bb file name Sep 01 08:49:45 ah ok, sorry I missed that Sep 01 08:49:50 it's supposed to correspond to the version of the package Sep 01 13:41:28 tomz2: ping Sep 01 13:44:08 captainigloo: pong, just updated the bug report Sep 01 13:44:39 :) Sep 01 13:45:08 what i get is verry strange Sep 01 13:45:57 captainigloo: seems like somehow you're building the wrong version of the x server? Sep 01 13:46:06 yes Sep 01 13:46:29 and the right xorg.conf is not copied in the rootfs Sep 01 13:46:57 it's why i tried with a wrong xorg.conf and not with the one present in emgd-driver-bin Sep 01 13:47:59 captainigloo: which one gets copied in? This has happened before, there was a bug months ago having to do with bbappend ordering, but that shouldn't be a problem any more. Sep 01 13:50:07 hum let me check Sep 01 13:50:27 one with the intel as driver Sep 01 13:50:41 intel string instead of emgd Sep 01 13:52:57 captainigloo: hmm, yeah, that's the default if nothing else gets picked up Sep 01 13:53:15 captainigloo: does bug http://bugzilla.pokylinux.org/show_bug.cgi?id=1072 describe it? Sep 01 13:54:46 captainigloo: that was caused by a layer priority issue, but that was fixed long ago. Sep 01 13:55:37 tomz2: yes it's my problem Sep 01 13:55:55 hum i'm using openeembedded-core with meta-intel Sep 01 13:56:47 a quick question: i just tried yocto and i'm a bit surprised that the runqemu command does not look in /sbin for ifconfig. Why doesn't it? Sep 01 13:58:42 tomz2: my bblayers.conf : http://pastebin.fr/12350 Sep 01 14:08:06 captainigloo: lots of layers - i guess the build must be picking up the default because the meta-crowbay layer priority isn't high enough? Sep 01 14:08:46 ERROR: Multiple .bb files are due to be built which each provide virtual/xserver-xf86 (/data/naguirre/LPG/angstrom-setup-scripts/sources/meta-intel/meta-crownbay/../common/recipes-graphics/xorg-xserver/xserver-xf86-dri-lite_1.9.3.bb /data/naguirre/LPG/angstrom-setup-scripts/sources/meta-openembedded/meta-oe/recipes-graphics/xorg-xserver/xserver-xorg_1.10.2.bb). Sep 01 14:09:19 tomz2: yep i will try with meta-crownbay on top Sep 01 14:18:55 andrnils: maybe its using PATH? Sep 01 14:20:10 possibly, but it looked for iptables in /sbin so I guess it is some assumption. I'm running on gentoo, so I expected some hurdles Sep 01 14:20:32 andrnils: If you can figure out why it didn't find it we take patches :) Sep 01 14:23:15 currently I'm just following the beta test blog instructions ( first time I try this ) so might take me some time to wrap my head around it. Sep 01 14:24:42 also I had problems executing "runqemu qemux86" Sep 01 14:25:10 but that was on a headless build machine, I'll try it again on my laptop Sep 01 15:58:02 where is the most up to date resources on build w/ multilib? i found a page on the wiki Sep 01 15:59:05 msm: Its not well documented at this point :/ Sep 01 15:59:40 andrnils: ok, please keep a note of issues like that (the PATH issue) Sep 01 16:00:44 RP__: fair enough, does it support building images yet or just building the packages? Sep 01 16:01:08 msm: It supports images Sep 01 16:01:56 how does one include a lib64 on a normal core-image-minimal? ive tried adding lib64-zlib in INSTALL_IMAGE Sep 01 16:02:07 better yet, is there an example somewhere? Sep 01 16:02:59 msm: That sounds right Sep 01 16:03:55 hmm, i could build lib64-zlib w/ bitbake, just not get it in an image Sep 01 16:04:13 do_rootfs complained lib64-zlib did not exist Sep 01 16:06:22 msm: It should work, offhand I don't know why it isn't Sep 01 16:06:52 k, i'll keep looking Sep 01 16:12:37 msm: Check the package exists and whether PACKAGE_ARCHS has the appropriate values Sep 01 16:12:51 msm: rootfs logs should show where its looking Sep 01 16:13:02 RP__: will rpm's be called lib64-zlib....rpm? Sep 01 16:13:32 msm: rpms may not be Sep 01 16:13:54 the package backend implementation details are different Sep 01 16:14:35 ok Sep 01 16:20:53 hi, I've some issues with pseudo: it tries to build pseudo each time....and never builds the image, where should I start debugging? Sep 01 16:21:30 ah I've found something interesting in the logs Sep 01 16:22:10 rpm, since it knows about multilibs, doesn't need to use a prefix to distinguish them.. it just uses the arch naming and can deal with conflicts as appropriate.. Sep 01 16:22:11 cat: .../oe-core/build/builddir/pseudodone: No such file or directory Sep 01 16:22:16 I'll investigate Sep 01 16:22:23 other packaging back ends do not have the name conflict resolution so hey do require unique package names Sep 01 16:23:04 fray: so, how do I say I want a 32 and 64 bit version in my final image? Sep 01 16:23:27 same way you would with any other packaging back end.. Sep 01 16:23:40 with OE you need to chose the recipes and (oe named) dependencies Sep 01 16:24:00 so a task with an OE dep of lib64-zlib will map to zlib...<64bit arch>.rpm Sep 01 16:26:05 so INSTALL_IMAGE += "lib64-zlib" should have worked Sep 01 16:26:11 yes Sep 01 16:26:20 good to know Sep 01 16:26:43 GNUtoo|work: if that stamp is missing that would cause problems so its the right place to look Sep 01 16:26:50 from a control/task point of view you should see no differences.. it's only on the target when using the packaging systems you will see differences (due to different capabilities) Sep 01 16:27:19 can you elaborate what the follow lines actually do: Sep 01 16:27:20 #MULTILIBS = "multilib:lib32" Sep 01 16:27:20 #DEFAULTTUNE_virtclass-multilib-lib32 = "x86" Sep 01 16:27:45 MULTILIBS = "multilib: [multilib:]" Sep 01 16:28:04 it enables building for an alt target? Sep 01 16:28:12 provides a list of available alternative multilibs and their associated identifies.. (this doesn't actually define them, only that they can exist and what to call them) Sep 01 16:28:22 so if my normal tune lets me build 32bit I only need a multilib:lib64 ? Sep 01 16:28:36 DEFAULTTUNE_virtclass-multilib- = "..." specifies the tune (defines) the multilib from the first setup Sep 01 16:29:18 RP__, there is a TMPDIR, but there is a BUILD_DIR too? Sep 01 16:29:23 so on a tri-arch system, you could do have the default be: machine could use mips n32... you then have MULTILIBS = "multilib:lib32 multilib:lib64" Sep 01 16:29:33 first setup being the first item in the MULTILIBS or the default tune? Sep 01 16:29:36 DEFAULTTUNE_virtclass-multilib-lib32 = "mipso32" Sep 01 16:29:47 DEFAULTTUNE_virtclass-multilib-lib64 = "mips64" Sep 01 16:29:53 ah Sep 01 16:29:57 you need to provide one for each Sep 01 16:30:15 *BUILDDIR Sep 01 16:30:27 now you have the abilitiy to specify all of the default ones (automatically n32 in that example).. or alternative ones for special cases (lib64 for large address space and o32 for legacy compatibility) Sep 01 16:30:42 mips is the "tri-lib" example.. Sep 01 16:31:00 right, thanks a ton for the explanation Sep 01 16:31:03 on a PPC system, you would usually have the default be 32-bit PPC.. and then specify lib64 as the alternative for large memory usage Sep 01 16:31:19 correct Sep 01 16:31:25 * fray notes his multilib talk got turned down for ELC Prague.. :( I was going to explain all of this and why people would want it... :( Sep 01 16:32:43 well, there is always IRC =) Sep 01 16:32:48 yup Sep 01 16:33:03 I have an introductory to Yocto talk at ESC Boston next month.. assuming I get my travel booked.. ;) Sep 01 16:33:17 so what needs to be done to recipes for them to support multilib? Sep 01 16:33:17 I'll likely mention multilibs, but I doubt I'll go into depth on them due to time.. Sep 01 16:33:26 in the best case? nothing Sep 01 16:33:31 it should be automatic.. Sep 01 16:34:02 in a few cases, it's no different then any other arch setup/patch.. recipes just have to be able to be configured for the various archs.. Sep 01 16:34:08 if they already build for one or the other they should just work Sep 01 16:34:32 so if you can build a stand-a-lone PPC64 and stand-a-lone PPC32 system, then you can build a multiarch system.. (assuming no file conflicts) Sep 01 16:34:32 how does this effect -sdk stuff? Sep 01 16:34:46 file conflicts are the most likely change.. two header files with the same filename and different contents.. Sep 01 16:34:57 two configuration files same name, different contents.. that kind of thing.. Sep 01 16:35:03 ive seen a class for that Sep 01 16:35:05 in those cases you will need to resolve the conflicting contents.. Sep 01 16:35:13 there is a class for the header files since that is most common Sep 01 16:35:27 for configuration files, man pages, etc.. each will likely require their own changes.. Sep 01 16:35:45 (man pages usually it's a mistake in the way the man pages were compressed.. timestamps were stored in the archive.. remove them and the conflicts disappear) Sep 01 16:36:31 dont those get packaged into separate packages anyways? Sep 01 16:36:51 package-doc Sep 01 16:36:56 package-dbg Sep 01 16:36:57 etc Sep 01 16:37:51 yes they do.. but if you are really supporting multilibs, you need to support arbitrary combinations of packages.. (even if generally someone wouldn't do it in a production environment) Sep 01 16:38:09 I'll go bye Sep 01 16:38:20 fair enough Sep 01 16:39:09 easiest test is construct a profile.. enable multilibs.. install that SAME profile with the multilibs.. (with rpm) so all of the conflict resolution kicks in.. that should give you all of the conflict errors.. Sep 01 16:39:12 do you know if the core-image-lsb recipes have been checked oiut for multilib yet? Sep 01 16:39:50 msm: There is a list of recipes that have been tested/worked on so far in multilib.conf Sep 01 16:39:51 RPM resolves conflicts by: is it elf - if so, follow the install policy -- generally no conflict is reported, one ELF version is choosen.. if it's NOT elf.. then reports a conflict based on filename & md5sum/sha being different Sep 01 16:40:21 msm, I checked much of core-image-lsb back when I did the original multilib work.. but I personally haven't checked it in about a month.. Sep 01 16:40:22 RP__: where? Sep 01 16:40:36 and I'm not sure I ever finished the work either.. I know Yocto/OE-core is quite good.. but I doubt it's perfect yet Sep 01 16:40:56 fray: yes, have you ever played around with setting up something like a yum repo with the yocto rpms? Sep 01 16:41:02 msm: meta/conf/multilib.conf Sep 01 16:41:19 not yum, we do use zypper repos.. the problem is that zypper (at this time) isn't setup to deal with multilibs.. Sep 01 16:41:26 RP__: ah thanks Sep 01 16:41:38 I personally don't like Yum due to the maintainer & also the fact it has more security holes in it then I can count.. Sep 01 16:42:01 * fray notes he can produce an RPM package, that added to a repo will erase your hard drive if you query the package with zypper and have sufficient permissions at the time.. :P Sep 01 16:42:17 that is simply crap IMHO Sep 01 16:42:37 fray: I just don't like its lack of cross compile support Sep 01 16:43:05 (yum has a nasty habit of trying to process RPM macros in-place while it queries.. and it's easy to introduce %(rm -rf /) into a description or summary.. Sep 01 16:44:25 also the yum maintainer refuses to work with anyone submitting rpm5 patches.. Sep 01 16:44:31 they exist.. but they're not in yum upstream Sep 01 18:23:09 im getting this error w/ libtool-cross Sep 01 18:23:10 cp: cannot stat `/local/home/mattsm/git/poky/build-mp5020ds/tmp/sysroots/p5020ds/usr/share/aclocal/*': No such file or directory Sep 01 18:23:32 there are no m4 macros installed in my sysroot Sep 01 18:23:52 im not sure if there should be at this point or not though Sep 01 18:24:22 depends on your configuration if there should be or not Sep 01 18:24:39 but why is libtool-cross failing today.... Sep 01 18:25:03 should it matter if there are none though? It should not fail Sep 01 18:25:57 I'm not sure at this point.. sorry Sep 01 18:26:51 adding an empty file to that folder lets things progress... Sep 01 18:27:10 well, that certainly sounds broken Sep 01 18:27:14 i could have had junk in there from some other build (i just started a new folder) Sep 01 18:27:25 new build folder Sep 01 18:44:01 fray: im still getting this w/ multilib Sep 01 18:44:02 | Processing lib64-zlib... Sep 01 18:44:02 | Unable to find package lib64-zlib (lib64-zlib)! Sep 01 18:44:16 the build step did make the lib64-zlib package just fine though Sep 01 18:44:28 which packaging back-end or is this before packaging? Sep 01 18:44:41 rpm Sep 01 18:44:49 this is the do_rootfs step Sep 01 18:45:51 how is lib64-zlib ending up in the list of packages to be installed, and what is the name of the produced package? zlib-...ppc64.rpm ? Sep 01 18:46:21 its not even make an rpm Sep 01 18:46:30 i only have one Sep 01 18:46:42 i added lib64-zlib to INSTALL_IMAGE Sep 01 18:46:51 what happens if you do bitbake lib64-zlib does it suddenly work? Sep 01 18:47:00 that step works Sep 01 18:47:08 infact building my image, it ran that step Sep 01 18:47:14 and a zlib-...ppc64.rpm ends up building Sep 01 18:47:18 ? Sep 01 18:47:32 what I'm trying to understand is hwat built (or didn't) Sep 01 18:48:02 right Sep 01 18:48:21 im looking a the lib64-zlib/temp/log.do_package_rpm Sep 01 18:48:46 it appears to have made some rpms Sep 01 18:48:59 besides that if I look at tmp/deply/rpm Sep 01 18:49:06 there is only 1 libz rpm Sep 01 18:49:10 tmp/deploy/rpm/ppce5500/libz1-1.2.5-r0.ppce5500.rpm Sep 01 18:49:18 ppce5500 which is the 32bit version Sep 01 18:49:34 tmp/deploy/rpm/... what other directories are there (besides all) Sep 01 18:49:57 only ppce5500 and p5020ds Sep 01 18:50:02 the two that would have been there Sep 01 18:50:20 w/o multilib Sep 01 18:50:34 the log.do_package_rpm what is in it for the lib64-zlib? Sep 01 18:51:54 it looks like it wrote some rpms to /local/home/mattsm/git/poky/build-mp5020ds/tmp/work/ppce5500-fslmllib64-linux/lib64-zlib-1.2.5-r0/deploy-rpms/ppce5500/ Sep 01 18:52:44 what was written there should have made it into tmp-eglibc/deploy/rpm.... Sep 01 18:53:16 but the contents of those files are not in the right folders, by that I mean the libz1.rpm file has libraries in /usr/lib not /usr/lib64 Sep 01 18:53:30 i only have tmp/ not tmp-eglibc/ Sep 01 18:54:32 thats fine.. Sep 01 18:54:44 thought so Sep 01 18:55:02 if the 64-bit rpm didn't put the stuff into /usr/lib64 then there is a tune error somewhere.. Sep 01 18:55:06 what is the tune you have for lib64? Sep 01 18:55:07 i haven o ppc64e5500.rpm though Sep 01 18:55:26 have no) Sep 01 18:56:04 BASE_LIB_tune-ppc64e5500 = "lib64" Sep 01 18:56:07 that? Sep 01 18:56:24 no, DEFAULTTUNE-virtclass-multilib-lib64 = ? Sep 01 18:56:31 ah Sep 01 18:56:35 ppc64e5500 Sep 01 18:56:57 ya, that and the base_lib_tune... should be enough.. Sep 01 18:57:13 I'm not sure.. bitbake -e and look at the variables and see if something is set to /usr/lib Sep 01 18:57:36 does it look at tune files for AVAILTUNES or something? Sep 01 18:57:55 or how does multilib back track from DEFAFULTTUNE to the right tune file? Sep 01 19:00:08 its putting /usr/lib everywhere Sep 01 19:00:55 the multilib class (automatically included) should be changing the values dynamically based on the the tune-... Sep 01 19:01:08 that is set by whatever virtclass-multilib-... you are using for a given recipe Sep 01 19:01:47 if I do: MACHINE=p5020ds bitbake lib64-zlib -e | grep DEFAULTTUNE Sep 01 19:02:08 I get: DEFAULTTUNE_MULTILIB_ORIGINAL="ppce5500" Sep 01 19:02:08 DEFAULTTUNE="ppce5500" Sep 01 19:02:20 its not changing for the lib64 case Sep 01 19:02:40 I'm not sure then.. RP is way better at diagnosing that stuff then I am Sep 01 19:03:10 ugh Sep 01 19:03:16 i see my issue Sep 01 19:03:26 DEFAULTTUNE_virtclass-multilib-lib32 = "ppc64e5500" Sep 01 19:03:28 whoops Sep 01 19:03:51 needs to be -lib64 Sep 01 19:03:52 i suspect Sep 01 19:04:17 yup.. :) needs to match Sep 01 19:04:37 I bet we should add a check (somehow) in the sanity or multilib that everything is configured properly Sep 01 19:04:45 I'd suggest you file a bug on that in the yocto bugzilla.. Sep 01 19:05:25 or should I say "enhancement" ;) Sep 01 19:05:31 i think ive gone and confused the heck out of my cache too Sep 01 19:05:39 or something in the tmp/ folder Sep 01 19:48:18 RP__: regarding ifconfig "issue": it's not an issue :) Sep 01 19:49:27 there are a couple of IFCONFIG=`which ifconfig`, which can be noisy. Sep 01 19:50:28 perhaps IFCONFIG=`which ifconfig 2> /dev/null ` is better Sep 01 19:50:44 andrnils: there is some kind of fallback after that? Sep 01 19:50:56 andrnils: but yes, that sounds better if we are trying that multiple times Sep 01 19:50:56 yes Sep 01 19:51:18 there is this: Sep 01 19:51:21 if [ -z "$IFCONFIG" ]; then Sep 01 19:51:21 # Is it ever anywhere else? Sep 01 19:51:21 IFCONFIG=/sbin/ifconfig Sep 01 19:51:21 fi Sep 01 19:51:59 So its just being noisy and confusing people Sep 01 19:52:18 seems so Sep 01 19:53:34 seems to be in oe-beta/scripts/runqemu-{gen-tapdevs,internal,ifup} Sep 01 19:54:55 andrnils: I'd normally suggest filing a bug but I just pushed a fix into master for this ;-) Sep 01 19:55:14 there seems to be a few more VAR=`which cmd` around, I might file a bug for those Sep 01 19:55:32 We should really add -x checks too Sep 01 19:55:46 i.e. ensure we actually find something Sep 01 19:56:29 can't hurt Sep 01 20:53:43 fray: my powerpc64 rpms are being produced correctly Sep 01 20:53:55 but still do_rootfs is getting confused trying to add lib64-zlib Sep 01 20:54:20 well good, one step forward.. what is the error? same thing? Sep 01 20:54:55 same thing Sep 01 20:55:01 can't find lib64-zlib package Sep 01 20:55:22 now tmp/deploy/rpm/powerpc64/zlib-1.2.5-r0.powerpc64.rpm exists Sep 01 20:55:29 which correct files in the package Sep 01 20:55:32 with* Sep 01 20:55:38 good Sep 01 20:56:05 in tmp/deploy/rpm there should be some configuration files (generated) does one of them list powerpc64 in the patch to _resolve_db ? Sep 01 20:56:10 'er.. in the path Sep 01 20:57:30 tmp/deploy/rpm/solvedb-base_archs.conf Sep 01 20:57:35 does not mention powerpc64 Sep 01 20:57:37 RP__: bug 1438 filed Sep 01 20:57:42 whereas it does list all the other arches Sep 01 20:58:56 hope the patch is usable Sep 01 20:59:23 let me look quick Sep 01 20:59:30 fray: yea, all these files lack any mention of powerpc64 folder Sep 01 20:59:45 only p5020ds, all, and ppce5500 Sep 01 21:00:06 there should be a few .conf files.. Sep 01 21:00:16 and there should be one for each of the directories in deploy/rpms Sep 01 21:00:31 I'll pick up again in the morning ( ~23.00 hrs ) in sweden now Sep 01 21:06:24 fray: http://pastebin.com/4S9G75Xu here is the full do_rootfs Sep 01 21:06:27 its skipping over powerpc64 Sep 01 21:07:13 odd Sep 01 21:07:28 for pkgdir in $packagedirs; do Sep 01 21:07:28 if [ -e $pkgdir/ ]; then Sep 01 21:07:28 echo "Generating solve db for $pkgdir..." Sep 01 21:07:34 I wonder if packagedirs is bad? Sep 01 21:09:26 about that Sep 01 21:09:32 for arch in $archs Sep 01 21:11:23 arches=all any noarch powerpc ppce5500 p5020ds Sep 01 21:11:27 powerpc64 is not on the list Sep 01 21:11:59 arches is evalated from archvar Sep 01 21:19:44 i think I need to set MULTILIB_PACKAGE_ARCH Sep 01 21:27:26 or PACKAGE_ARCHS per the earlier suggestion Sep 01 22:06:06 seems like my rpm install problem is related to MLPREFIX not getting set Sep 01 22:07:32 this is not set for my image recipe Sep 01 22:07:43 its set fine for the lib64-zlib case Sep 01 22:08:14 but it barfs package_install_internal_rpm Sep 01 23:22:31 ok so if I set MULTILIB_IMAGE_INSTALL = "lib64-zlib" instead of IMAGE_INSTALL it builds everything (incl. lib64-zlib) but it just does not install it into the generated image **** ENDING LOGGING AT Fri Sep 02 02:59:57 2011