**** BEGIN LOGGING AT Tue Dec 13 02:59:57 2011 Dec 13 07:45:58 hi i am running the yocto kernel 2.6.37 on a mpc8315e-rdb board. as compared to the kernel 2.6.24 which freescale provides, i find some of the boards kernel drivers are missing from the yocto kernel yocto/standard/fsl-mpc8315e-rdb branch. how completely does the yocto kernel support the mpc8315e-rdb? Dec 13 07:46:07 i heard that it is quite complete Dec 13 07:46:36 but i cant find some drivers like the tdm driver, spi driver... Dec 13 08:50:46 morning all Dec 13 10:05:23 Hi all, the testresults displayed on the wiki using LTP and the POSIX test suite, can I find these recipes at git.yoctoproject.org ? Dec 13 10:17:35 d4ny: Currently our QA people run them manually but we're about to merge recipes for some of them Dec 13 10:17:53 d4ny: We're working on automating it Dec 13 10:45:01 morning Dec 13 11:10:18 otavio: morning Dec 13 11:10:41 otavio: your connman patch is frustrating me a little - you're removing things you added in the last patch Dec 13 11:17:48 RP__: not really; I cleaned up what it used to have Dec 13 11:19:05 RP__: I tried to not remove much stuff and some came from meta-oe .inc file that I didn't noticed that could be removed at that moment Dec 13 11:29:03 RP__: Good to know. Any possiblity to get a sneek peek at whats about to arrive ? Dec 13 12:00:09 d4ny: the patches were posted for review on the mailing list Dec 13 12:00:31 d4ny: other work has bugzilla entries and is ongoing but no code yet Dec 13 12:00:31 RP__: Ah, thanks RP__ Dec 13 13:10:23 otavio: For reference the dosfsutils change has broken large images :( Dec 13 13:21:41 RP__: has it? i've been using it here without problems Dec 13 13:21:54 RP__: do you have an use-case for me to test? Dec 13 13:22:59 nitink: btw, when you have time I would like to sit and look at the dosfsutils segfault case Dec 13 13:23:17 nitink: that is important to me to fix since it will allow me to merge some more patches Dec 13 13:24:03 otavio: bitbake core-image-sato-sdk and its large enough that it fails. It seems it happens if we go into fat32 territory Dec 13 13:24:40 otavio: If I pass -F 16, it works Dec 13 13:24:49 RP__: good Dec 13 13:25:00 RP__: I'll try that here and see if I find the problem Dec 13 13:25:17 RP__: I might have done something wrong while merging the patches Dec 13 13:25:38 otavio: http://autobuilder.pokylinux.org:8010/builders/crownbay-noemgd/builds/39/steps/shell_30/logs/stdio is an illustration of the failure Dec 13 13:25:51 otavio: I'm wondering if one of the patches doesn't correctly support fat32 Dec 13 13:26:30 RP__: but this used to work with previous dosfsutils, right? Dec 13 13:26:45 RP__: or has it moved from fat16 to fat32 recently? Dec 13 13:26:45 otavio: 2.11 adds in the bit "Auto-selecting FAT32 for large filesystem" Dec 13 13:26:56 otavio: it seems that "triggers" it Dec 13 13:27:22 RP__: is it possible for you to check if previous image had the final fs as fat16? Dec 13 13:27:35 otavio: already did, it used fat16 before Dec 13 13:27:42 RP__: if that's the case, then this indeed has been around and unnoticed before Dec 13 13:27:51 RP__: seems related then Dec 13 13:29:00 RP__: is nitink who is suppose to work at this? the other dosfsutils bug is assigned to him so I'd like to share work with who can help me on that Dec 13 13:30:20 otavio: he does look after those recipes, I'm not sure how much detailed knowledge he has of the code Dec 13 13:31:08 nitink: please ping me when you can so we talk about those issues... Dec 13 13:31:14 nitink: I'd like to help with them Dec 13 13:47:11 otavio: I suspect the -d option patch is incompatible with fat32 Dec 13 13:52:15 RP__: it might be Dec 13 13:57:30 otavio: I'm going to disable the fat32 autoselection Dec 13 13:58:51 RP__: right Dec 13 16:53:41 otavio: I have not looked at the dosfsutils bug, and if you can help that would be great ! Dec 13 16:54:04 otavio: today I will look at the bug, to understand the issue better Dec 13 16:54:50 nitink: I can, sure. So take a look and we talk about it Dec 13 16:57:14 otavio: alright Dec 13 17:00:02 otavio: As I understand there are 2issues with dosfstools now, 1st is -d segfault as mentioned in the bug, and 2nd fat32 issue RP mentioned Dec 13 17:08:41 nitink: yes Dec 13 17:09:04 nitink: the most urgent seems to be the segfault specially because it fixes the bootimg use too Dec 13 17:10:26 dvhart: is the dosfstools bug a regression? has it worked before? Dec 13 17:11:16 nitink, the bootimg was definitely a regression Dec 13 17:11:31 nitink, not sure about the other one, haven't looked at it Dec 13 17:11:33 dvhart: so something broke the tool Dec 13 17:11:47 at least for the segfault bug Dec 13 17:12:09 the bootimg issue has been addressed with the last dosfstools commit from RP Dec 13 17:17:24 dvhart: do you mean the segfault issue with -d option is gone now ? Dec 13 17:18:02 nitink, I don't know which bug that characterizes. The issue where bootimg would fail (due to an error like "too many fat entries" or something along those lines) is now fixed. Dec 13 17:18:36 svhart: this sounds like same issue what you filed a while back: http://bugzilla.pokylinux.org/show_bug.cgi?id=1783 Dec 13 17:18:41 nitink, do you have a link to the autobuilder stdio log that is the bug you are working on? Dec 13 17:18:50 ah no Dec 13 17:18:54 that is a different bug Dec 13 17:19:07 that bug prevents us from creating a proper EFI boot filesystem Dec 13 17:19:12 dvhart: I think RP fixed this issue: http://autobuilder.pokylinux.org:8010/builders/crownbay-noemgd/builds/39/steps/shell_30/logs/stdio Dec 13 17:19:20 and this is why we cram everything into the root dir on the hddimg Dec 13 17:19:38 1783 is still an outstanding issue as far as I know. Dec 13 17:19:47 I haven't tested it since the dosfstools update though Dec 13 17:19:51 ok, I can look at 1783 Dec 13 17:20:05 dvhart: can you test and let me know if the bug is still there Dec 13 17:20:15 sorry, I didn't realize you were talking about that. Dec 13 17:20:25 nitink, I see no reason that it shouldn't be, but yes, I can do that Dec 13 17:20:26 meanwhile I will try to debug it natively Dec 13 17:21:11 possibly it was fat16/fat32 issue which RP commit may be fixing Dec 13 17:21:40 So when rebuilding some recipes with EXTRA_OECONF = "--libdir=${base_libdir}" that the pkgconfig directory also ends up under base_libdir. I've been moving the directory back to libdir in a do_install_append function. Is there a better way of doing this? Dec 13 17:21:55 I found the PKG_CONFIG_DIR variable, but setting it in the recipe does not appear to do what I assumed it does. Dec 13 17:22:23 PKG_CONFIG_DIR is where to look for pc files, iirc Dec 13 17:23:02 let me double-check why that wasn't working for me then Dec 13 17:24:40 I mean to say it's where pkg-config will look for pc files at configure time, rather than where autotools will install them Dec 13 17:25:43 incandescant, ah Dec 13 17:25:53 that would explain the issue Dec 13 17:26:02 I guess just moving the directory manually is the thing to do then Dec 13 17:26:51 zenlinux_: if you find yourself repeating the same pattern several times it may be that we need a new class or method? Dec 13 17:27:25 Well, hopefully it's only 4 or 5 recipes I need to do this to - I haven't gone all the way down the rabbit hole yet Dec 13 17:27:49 good luck Alice! Dec 13 17:28:12 :) Dec 13 17:29:03 fray, in other news - it definitely looks like the shadow-utils are locking the group and passwd files, and they aren't retrying when they can't get the lock. Do I recall you saying you had a patch for that awhile back? Dec 13 17:47:42 nitink, dosfstools -d is still an issue Dec 13 17:48:51 dvhart: thanks for validating, btw can you give me a zip/tarball with the filesystem you want for efi Dec 13 17:49:09 sure Dec 13 17:49:10 dvhart: I can try to create image with that directory Dec 13 17:58:56 RP__, fray, handling libraries in /lib that link to /usr/lib is becoming a sisyphean exercise - each library I'm relocating to /lib then fails the QA test because it too links to something else under /usr/lib Dec 13 17:59:25 that usually indicates a fairly severe design problem.. Dec 13 18:00:01 udev links to libusb, glib-2.0, links to libffi, etc Dec 13 18:00:01 in the past when I've gotten to that point.. I create a dep tree as best I can to understand why the library is there (user) and all of the dependencies so I can figure out architecturally the fix, vs mechanically Dec 13 18:00:32 zenlinux_: the shadow issue you mention above is that related to 1721? Dec 13 18:00:46 zenlinux_: do you have a patch for that soon? Dec 13 18:01:30 sgw, no and no Dec 13 18:01:42 Ok Dec 13 18:01:56 * sgw aftk Dec 13 18:02:06 if the login.defs file doesn't exist, that's a different issue than the locking issue with group/passwd that someone (I think RP) commented on this morning in another bug Dec 13 18:03:38 fray, RP__, I'd like to suggest we approach this QA test in piecemeal and save the /lib testing for a different milestone Dec 13 18:04:04 I'm still concerned about an architecural failure.. Dec 13 18:04:15 is udev required prior to /usr being mounted? Dec 13 18:04:18 otherwise this P2 feature is going to seriously get in the way of my P1 feature in M2, the bitbake error handling refactoring Dec 13 18:04:49 ya, I understand.. I think the QA test you have created is fine.. you've found a bug, one that we need to understand and fix.. but that can be a later milestore.. Dec 13 18:04:50 fray, I don't know if udev is required prior to /usr being mounted...that's not what the QA test is testing Dec 13 18:05:17 I'd simply make the current case a warnign then if it's not resolveable.. file a bugzilla defect and we need to figure this out Dec 13 18:05:36 (BTW these are exactly the type of bugs I expected to find with this test.. so it proves it's working) Dec 13 18:05:41 yep Dec 13 18:13:55 dvhart: Are you able to give connman a build test with a tentative fix? Dec 13 18:39:58 hi, me and someone who is working with me on adding a meta/conf/machine/include/arm/arch-armv6.inc in openembedded-core have a question: Dec 13 18:40:22 what is correct between: Dec 13 18:40:23 PACKAGE_EXTRA_ARCHS_tune-armv6t-novfp ?= "${PACKAGE_EXTRA_ARCHS_tune-armv5e} armv6" Dec 13 18:40:36 and: Dec 13 18:40:38 PACKAGE_EXTRA_ARCHS_tune-armv6t-novfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5e} armv6 armv6t-novfp" Dec 13 18:40:46 s/=/?=/ Dec 13 18:41:17 just a sec Dec 13 18:41:31 ok Dec 13 18:41:39 isn't there already an arch-armv6.inc? Dec 13 18:41:47 yes but it supports only -vfp Dec 13 18:41:54 basically there was an error Dec 13 18:41:59 ahh I see.. Dec 13 18:42:13 and the person doing that file assumed that there were no armv6-novfp machines Dec 13 18:42:21 ignore my teeth mashing, as I implemented a novfp version -- but I was specifically told there was never an armv6 w/o vfp.. Dec 13 18:42:22 :P Dec 13 18:42:28 but since I've one on my desk it must be wrong Dec 13 18:42:32 trust me, I assumed the opposite Dec 13 18:42:33 htcdream machine Dec 13 18:42:45 ok Dec 13 18:42:47 let me see if I can find the original version of the file Dec 13 18:42:53 might take me a few mintues Dec 13 18:42:59 thanks a lot Dec 13 18:43:21 I even sent a patch proposing a fix some time ago but it was refused because it would break current builds Dec 13 18:43:27 the patch did that: Dec 13 18:43:36 armv6 -> armv6-novfp Dec 13 18:43:45 and added armv6-vfp Dec 13 18:43:55 but that will obviously break current builds Dec 13 18:44:36 well I find the thread you mention.. but not the original set of code.. Dec 13 18:44:39 otavio, sure Dec 13 18:44:49 otavio, where is said fix? Dec 13 18:44:49 me and someone else got a patch that we tested and it seem that both way work (PACKAGE_EXTRA_ARCHS_tune-armv6t-novfp ?= "${PACKAGE_EXTRA_ARCHS_tune-armv5e} armv6" vs PACKAGE_EXTRA_ARCHS_tune-armv6t-novfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5e} armv6 armv6t-novfp" ) Dec 13 18:45:06 hmmm maybe I should git log on it Dec 13 18:45:18 the problem is there are distributions out there that assume armv6 (package feed) means there is vfp.. thus the request for the novfp version Dec 13 18:45:24 Add ARM tune file overhaul based largely on work from Mark Hatle Dec 13 18:45:25 because as you know all armv6 include vfp.. Dec 13 18:45:28 Dec 13 18:45:45 the stuff was never checked in that I produced because it was denied.. Dec 13 18:46:11 ok.. so the thread I found says you need to implement Dec 13 18:46:19 armv6-novfp as the new architecture.. Dec 13 18:46:33 for the package_extra_archs it should include only armv5, not armv6 Dec 13 18:46:45 the armv6 should be amended to include the armv6-novfp version Dec 13 18:46:52 ok Dec 13 18:47:01 that answer your question? Dec 13 18:47:38 yes, thanks Dec 13 18:47:40 right Dec 13 18:47:48 because it's *extra* archs Dec 13 18:48:19 let me know if you have any other quetions.. (this is one of those things that still ticks me off.. I knew there were non vfp armv6 machines, and was told over and over they didn't exist.. and I couldn't find a counter example) Dec 13 18:48:22 dvhart: https://github.com/OSSystems/oe-core/commit/b735c3a13c05df3a8895beda5a1181119610d815 Dec 13 18:48:24 so my implementation got thrown out Dec 13 18:48:30 the armv6 should be amended to include the armv6-novfp version <- what do you mean exactly ? Dec 13 18:48:39 dvhart: if this fail to build, please paste your config.log Dec 13 18:48:43 fray, ok Dec 13 18:48:46 np Dec 13 18:48:54 otavio, have you tested the build with poky? Dec 13 18:49:06 dvhart: no; I only use oe-core Dec 13 18:49:22 ok, and it builds there I take it? Dec 13 18:49:30 dvhart: yes Dec 13 18:49:47 dvhart: but I failed to reproduce this build failure before too Dec 13 18:49:56 dvhart: that's why i am asking you to test Dec 13 18:50:01 ok Dec 13 18:50:24 sorry my network just dumped.. Dec 13 18:50:29 np Dec 13 18:50:32 I told that: Dec 13 18:50:35 (you'll likely get this again when it decides to come back) Dec 13 18:50:35 the armv6 should be amended to include the armv6-novfp version <- what do you mean exactly ? Dec 13 18:50:35 PACKAGE_EXTRA_ARCHS_tune-armv6 = "${PACKAGE_EXTRA_ARCHS_tune-armv5e-vfp} armv6-vfp" Dec 13 18:50:35 PACKAGE_EXTRA_ARCHS_tune-armv6t = "${PACKAGE_EXTRA_ARCHS_tune-armv5te-vfp} armv6-vfp armv6t-vfp" Dec 13 18:50:35 PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf-vfp" Dec 13 18:50:35 PACKAGE_EXTRA_ARCHS_tune-armv6thf = "${PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp} armv6hf-vfp armv6thf-vfp" Dec 13 18:50:46 each of those needs the armv6-novfp added to it Dec 13 18:50:54 ok Dec 13 18:51:00 since they are automatically compatible.. Dec 13 18:51:11 right Dec 13 18:51:18 'er wait.. no.. I'm wrong the hf items are NOT compatible w/ the novfp.. Dec 13 18:51:23 so it is only the first two.. Dec 13 18:51:28 yes Dec 13 18:51:28 (hf is a different ABI) Dec 13 18:51:32 yes I know Dec 13 18:51:37 why we don't build hf btw Dec 13 18:51:37 ? Dec 13 18:51:42 because hf is faster Dec 13 18:51:42 my networking is coming back on.. sorry for the paste flood thats about to happen.. :P Dec 13 18:51:47 hf requires vfp Dec 13 18:51:56 yes I know Dec 13 18:52:03 I meant on armv7 for instance Dec 13 18:52:10 People want compatibility Dec 13 18:52:19 if you don't want compatibility the hf versions are there for you today Dec 13 18:52:21 for instance there is a debian hf Dec 13 18:52:59 or at least a plan to do it Dec 13 18:53:04 I don't know in which state it is Dec 13 18:53:16 AFAIK, there is a Canonical HF because of Linaro.. Dec 13 18:53:20 ok Dec 13 18:53:20 everyone else is just riding along Dec 13 18:53:31 ah ok Dec 13 18:53:32 GNUtoo: it has been merged into sid recently Dec 13 18:53:36 HF is fine for newer systems, but it's the compatibility that is the issue.. Dec 13 18:53:36 GNUtoo: so debian has it now Dec 13 18:53:43 ok nice Dec 13 18:53:53 there is a lot of (proprietary) software still in the embedded market that requires standard EABI.. Dec 13 18:53:55 * otavio is DD ;-) Dec 13 18:53:59 ah ok Dec 13 18:54:22 so in systems where we have all the source(like SHR) we could switch to hf maybe Dec 13 18:54:29 JaMa, what do you think? Dec 13 18:54:41 the problem, from what I can tell, is the people who created HF, didn't bother with the compatibility question.. so there is no way to distringuish between the two, and no way to build a system that could support both ABIs.. which is -really- stupid Dec 13 18:55:33 maybe we would need first to get separate feeds between archs Dec 13 18:55:39 (in SHR) Dec 13 18:55:39 otavio, configure fails Dec 13 18:55:41 otavio, http://pastebin.com/LkNrdM6e Dec 13 18:56:09 the way it's set up now, in OE-core, you should be able to construct non-conflicting feeds Dec 13 18:56:20 the names should be unique Dec 13 18:58:32 thanks a lot Dec 13 18:58:44 I'll reread everything and modify that file Dec 13 18:59:08 ya, it's taking a bit for it to come back to me.. but the design is all supposed to be "addative".. so new variants are easy to add.. Dec 13 18:59:29 the armv6-novfp is not unqiue enough to be it's own variant.. so what you are doing is the right way.. Dec 13 18:59:41 if it was a unique part (nobody else would ever do it that way) then I'd suggest a less generic approach Dec 13 19:02:07 dvhart: please paste config.log from tmp Dec 13 19:02:22 dvhart: the configure log, not do_configure Dec 13 19:02:34 otavio, ah right, sorry Dec 13 19:04:03 heh np Dec 13 19:05:34 http://pastebin.com/xgVH3teu Dec 13 19:05:38 doing too many things as once Dec 13 19:09:47 dvhart: what version of linux-libc-headers have you built? Dec 13 19:18:11 dvhart: do you have /build/poky/fri2/tmp/sysroots/fri2-noemgd/usr/include/linux/if_alg.h Dec 13 19:20:36 FWIW hard float is overrated on arm Dec 13 19:20:55 dvhart: my sysroot has this file Dec 13 19:21:00 * dvhart looks Dec 13 19:21:01 dvhart: do your sysroot has it? Dec 13 19:21:50 khem, I do not have that file Dec 13 19:22:24 otavio, linux-libc-headers-yocto-2.6.37 Dec 13 19:22:25 dvhart: thats the problem Dec 13 19:22:37 ah I think that might be recent Dec 13 19:22:43 do u have 3.1 headers Dec 13 19:22:47 installed somewhere Dec 13 19:22:59 yeah, on my dev box, checking Dec 13 19:23:44 yeah, fedora 2.6.41 headers (ie 3.1.0) do have if_alg.h Dec 13 19:23:58 that file is relatively new actually Dec 13 19:24:06 so 2.6.37 might not have it Dec 13 19:24:11 khem: 2.6.39 added it Dec 13 19:24:35 dvhart: but current oe-core uses newer headers, no? Dec 13 19:24:37 but if we are going to ship 3.x kernels, we need to get the linux-headers updated Dec 13 19:24:40 otavio: so the new version of this con-man :) wont work with older kernel Dec 13 19:24:47 otavio, depends on which kernel you use Dec 13 19:24:59 khem: no; this is used on a single binary Dec 13 19:25:02 otavio, sorry, depends on which linux-libc-headers you select Dec 13 19:25:04 khem: alg-test Dec 13 19:25:27 otavio: so disable that test based on kernel version then Dec 13 19:25:27 so we need a way to configure that out for libc headers < 2.6.39 Dec 13 19:25:29 dvhart: and poky forces .37 in this case Dec 13 19:25:42 otavio, checking if it is poky or BSP Dec 13 19:25:43 otavio: change connman's configure to detect the kernel version before that test Dec 13 19:25:54 khem, agreed, that is the proper fix here Dec 13 19:26:00 khem: yes Dec 13 19:26:02 or make it not fret about it Dec 13 19:26:04 b/c even if we update, others may still want to use an older kernel Dec 13 19:26:13 correct Dec 13 19:26:14 dvhart: but at least we found why this fails Dec 13 19:26:15 erm, headers Dec 13 19:26:18 otavio, yup Dec 13 19:26:22 \o/ Dec 13 19:27:09 usually its best to use same kernel sources for headers and kernel in use but that may not always be the case Dec 13 19:27:27 older kernel headers on newer kernel are pretty common practice Dec 13 19:27:38 fray, http://www.pastie.org/private/v445klyfjfu05mtzkvjfww and http://www.pastie.org/private/rvad9ylqbt6rxhzrrrl2rg is ok? Dec 13 19:28:37 just a sec Dec 13 19:31:43 dvhart: I will cook a patch for this and ask you for a new test Dec 13 19:31:51 dvhart: but not today heh Dec 13 19:32:19 otavio, cool Dec 13 19:33:14 GNUtoo: +PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp}" Dec 13 19:33:33 shoudnt that be +PACKAGE_EXTRA_ARCHS_tune-armv6hf = "${PACKAGE_EXTRA_ARCHS_tune-armv5ehf-vfp} armv6hf-vfp" Dec 13 19:33:48 no.. it doesn't include itself Dec 13 19:34:12 khem, I don't think so, hard float and soft float are compatible? Dec 13 19:34:19 only other comment.. no big endian version Dec 13 19:34:20 ah sorry Dec 13 19:34:29 yes I'll do it right after Dec 13 19:34:33 (is there, should there be one?) Dec 13 19:34:36 khem, sorry I didn't see the hf Dec 13 19:34:55 fray, I don't own any big endian arm machines so I don't know Dec 13 19:35:10 ya, I've never seena big endian armv6 no vfp Dec 13 19:35:11 GNUtoo: you own one if you own a LE machine Dec 13 19:35:18 they are configurable Dec 13 19:35:25 khem, trough bootloader I guess Dec 13 19:35:31 there is one bit you set in CP15 to configure endianness Dec 13 19:35:33 like very early init sequence Dec 13 19:35:38 ok Dec 13 19:35:50 khem, I didn't think a lot of cpus had that implemented Dec 13 19:36:00 ('er.. a lot of 'custom' cpus) Dec 13 19:36:26 fray: most of them do its standard part of CP15 regset Dec 13 19:38:34 yes but what if you have a proprietary bootloader, that's whithout hope? Dec 13 19:40:05 GNUtoo: it does not hurt, I dont think there will be BE option that common but to keep it there it should be ok Dec 13 19:40:24 so I add it and hope it works? Dec 13 19:41:26 I've also just received some imx from work, but I guess they are all vfp Dec 13 19:41:31 *for work Dec 13 19:41:39 25,35,51 Dec 13 19:41:55 imx is armv7-a + vfp Dec 13 19:42:26 depend on the model Dec 13 19:42:35 I've also a 31 and it's armv6 with vfp Dec 13 19:42:41 (bug 1.x) Dec 13 19:44:03 ok they all should have vfp Dec 13 19:44:14 so my only machine without vfp has a non-free bootloader Dec 13 20:27:00 ka6sox, fray now I have that again: Error, the PACKAGE_ARCHS variable does not contain TUNE_PKGARCH (armv6t). Dec 13 20:27:41 I guess it's because I removed self assignement in package extra archs Dec 13 20:27:46 but I was told to do it Dec 13 20:28:09 I thoguth self assignment wasn't necessary.. but frnakly I can't remember.. you need to check the existing examples Dec 13 20:28:30 but this isn't complaining about PACKAGE_ARCH_EXTRAS.. but PACKAGE_ARCHS Dec 13 20:28:33 PACKAGE_EXTRA_ARCHS_tune-armv5b-vfp = "${PACKAGE_EXTRA_ARCHS_tune-armv5} armv5b-vfp" Dec 13 20:28:49 these are two separate things, it hought Dec 13 20:28:54 let me verify Dec 13 20:29:24 PACKAGE_ARCHS = "all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}" Dec 13 20:29:28 from bitbake.conf Dec 13 20:29:43 ok.. then yet, it will need to reference itself afterall Dec 13 20:29:57 but armv6t is wrong anyway.. it should be armv6t-novfp Dec 13 20:30:05 (since thumb allows for vfp doesn't it?) Dec 13 20:31:24 ok let me remove sanity and do a bitbake -e Dec 13 20:32:48 hmmm Dec 13 20:32:54 I'll try to debug it Dec 13 20:36:20 'er.. I just noticed there is a circular dependency between gettext and libiconv.. how does bitbake deal with that? Dec 13 20:36:45 libiconv requires virtual/gettext, and gettext requires virtual/libiconv.. Dec 13 20:37:31 Hmm.. I bet it's the gettext-native? Dec 13 20:38:16 # TUNE_PKGARCH=${@d.getVar('ARMPKGARCH', True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU} Dec 13 20:38:17 hmmm Dec 13 20:38:37 that is generated based on the tune falgs Dec 13 20:38:39 'er.. flags Dec 13 20:38:59 so you must have armpkgsfx_thumb enabled... to get the 't' Dec 13 20:39:08 'ARMPKGARCH' -> armv6 ARMPKGSFX_THUMB -> t Dec 13 20:39:25 but.... Dec 13 20:39:27 # ARMPKGSFX_FPU=${@bb.utils.contains("TUNE_FEATURES", "vfp", "-vfp", "" ,d)} Dec 13 20:39:29 I suspect that armpkgsfx_fpu should be set to -novfp Dec 13 20:39:40 you'll need to add something specific for this case Dec 13 20:39:42 indeed but only for armv6 Dec 13 20:40:09 ARMPKGSFX_FPU .= ${....if arch is armv6, then -novfp otherwise -vfp) Dec 13 20:40:20 ah? Dec 13 20:40:27 I tought of an override Dec 13 20:40:38 ARMPKGSFX_FPU_armv6 Dec 13 20:40:54 I'm not sure that will work because this is evaluated before the overrides Dec 13 20:41:04 (the result of this, I think is fed into the overrides) Dec 13 20:41:06 lol ok Dec 13 20:41:34 ls Dec 13 20:41:35 oops Dec 13 20:50:13 fray: usually libiconv comes from eglibc Dec 13 20:50:30 fray: but with uclibc it needs to use libiconv Dec 13 20:50:47 I'm not sure that will work because this is evaluated before the overrides => it fails: Dec 13 20:50:59 fray: gettext class should take care of the circular deps though Dec 13 20:51:10 http://www.pastie.org/private/lnhwwhqz2trhtrwyafq9mq Dec 13 20:52:22 so I guess I've to move ARMPKGARCH evaluation before Dec 13 21:06:31 but how do I do that? **** ENDING LOGGING AT Wed Dec 14 02:59:57 2011