**** BEGIN LOGGING AT Wed Jan 04 02:59:58 2012 Jan 04 06:35:16 any one got a mesa package error http://pastebin.com/9c6ARZLc ,i am compiling it for uclibc Jan 04 07:15:54 erwt: which version of uclibc are u using Jan 04 07:17:00 khem, uclibc-0.9.30.2-r35.1 Jan 04 07:18:10 erwt: does it have this patch http://git.uclibc.org/uClibc/commit/?id=956a0087e282e53ba9c085dbbc469391f7234944 Jan 04 07:18:23 if not then backport it Jan 04 07:19:03 i think its not Jan 04 07:19:22 bcoz i am getting that log2f error Jan 04 07:23:14 khem, its not applied ,but after applying the patch should i recompile it Jan 04 07:24:02 yes recompile uclibc Jan 04 07:27:11 khem, i even got an error on versionsort during alsa copilation ,do u know the patch for it ,my http://pastebin.com/2rCA7MDp Jan 04 07:27:33 src/ucm/parser.c:1138: err = scandir(filename, &namelist, filename_filter, versionsort); in alsa folder Jan 04 07:36:39 khem, thnk Jan 04 07:40:06 erwt: backport this http://git.uclibc.org/uClibc/commit/?id=1a2c9641465f2c64fbb49749688ca465ad3cd6fe Jan 04 08:19:37 khem, can you get into agate? Jan 04 09:15:53 Tartarus: pong Jan 04 09:46:25 mornin Jan 04 10:03:02 morning all Jan 04 10:04:05 hi bluelightning Jan 04 10:05:20 hi all Jan 04 10:05:26 hi Jan 04 10:05:52 is nitink1 ever awake on IRC? what timezone is he hin? Jan 04 10:16:06 khem, it works ,both of your link Jan 04 10:18:27 Jin|away: I think he lives in California **** BEGIN LOGGING AT Wed Jan 04 10:54:15 2012 Jan 04 11:32:18 hi. i've got a bionic rootfs and i'd like to add some stuff (glibc, thttpd, wget, curl, and maybe some other cmd line tools like if/wconfig) to it using OE, would console-image be the right recipe to edit to generate a rootfs image that is as small as possible Jan 04 11:43:05 can somebody help me with these two errors during parsing? i also appended my local.conf. http://paste.pocoo.org/show/529767/ Jan 04 12:17:34 cryptix, i think you should check your checksum no in yourfile.bb Jan 04 12:17:50 the no may not be valid Jan 04 12:25:45 PaulePanter, there ? Jan 04 12:35:53 erwt: i havnt touch the two .bb Jan 04 12:46:55 could bitbake have problems with my git? both .bb's use git as their scm Jan 04 12:51:17 cryptix, sorry not much idea abt that Jan 04 13:04:11 sigh... 'The current release series is BitBake 1.8 and the current release is 1.8.18.'.. somebody might want to update this... Jan 04 13:06:08 where does it say that? Jan 04 13:06:21 http://docs.openembedded.org/usermanual/usermanual.html#gettingoe_getting_bitbake Jan 04 13:08:03 same goes for the .pdf version Jan 04 13:12:33 ah, right Jan 04 13:13:29 thankfully i fell over the 2011.03 release notes Jan 04 13:21:00 cryptix: unfortunately you missed the switch to oe-core :/ Jan 04 13:28:03 since im just getting started with oe it might not be too late ^^ Jan 04 13:33:30 cryptix: pls read this Jan 04 13:33:32 http://www.openembedded.org/wiki/OpenEmbedded-Core Jan 04 13:33:41 http://www.openembedded.org/wiki/LayerIndex Jan 04 13:33:51 the main page will be update supposedly soon Jan 04 13:34:16 this sounds really good Jan 04 13:35:01 yeah.. hopefully.. the 'deprecated state of oe-classic should be more visible Jan 04 13:35:59 you sse, there are still users which preferred to finish their projects with oe-classic Jan 04 13:36:23 but they said they'll move to oe-core asap Jan 04 13:37:07 we know it is confusing... Jan 04 13:39:58 i see. that's reasonable, too. Jan 04 13:40:49 maybe you should keep that bitbake version stumbling block in the documentation in the meantime ^^ Jan 04 13:42:57 cryptix: those pages should be removed alltogether once th etransition is definitive Jan 04 13:52:51 Hi all Jan 04 13:53:49 I use libgcrypt for my board and it is cross compiled up to my target Jan 04 13:54:02 I want to compile libcrypt also for native Jan 04 13:54:29 can I tell bitbake compile any package for native? Jan 04 13:54:51 I mean without editing bb file Jan 04 13:54:51 mgundes, ya if it is in recipe Jan 04 13:55:14 I need libgcrypt for my native application Jan 04 13:56:07 if I use DEPENDS in my application receipe as DEPENDS="libgcrypt" then libgcrypt will also compiled for native? Jan 04 13:56:11 am I right? Jan 04 14:03:38 mgundes: yes, because in libgcrypt.inc there is BBCLASSEXTEND = "native" Jan 04 14:06:15 mgundes: your (native) app will depend on libgcrypt-native Jan 04 14:08:28 hm, in my app bb I should tell DEPENDS="libgcrypt-native" Jan 04 14:08:49 ok thanks ant_work, I will try Jan 04 14:14:42 03Paul Eggleton  07master * ra228f0a32c 10bitbake.git/bin/bitbake-layers: (log message trimmed) Jan 04 14:14:42 bitbake-layers: fix Python error during parse Jan 04 14:14:42 If "bitbake-layers show_layers" was run when the cache was dirty forcing Jan 04 14:14:42 a parse, it failed with the following error: Jan 04 14:14:42 ERROR: Failure expanding variable SRCPV, expression was Jan 04 14:14:43 ${@bb.fetch2.get_srcrev(d)} which triggered exception AttributeError: Jan 04 14:14:44 'module' object has no attribute 'fetch2' Jan 04 14:19:31 03Juraj Hercek  07master * r1f2867b79f 10bitbake.git/lib/bb/fetch2/git.py: (log message trimmed) Jan 04 14:19:31 fetch2/git: change colon to dot in ud.host Jan 04 14:19:31 Local cloning of git repositories from DL_DIR into WORKDIR fails when Jan 04 14:19:31 using ssh URL with port specification e.g. Jan 04 14:19:31 "ssh://user@host:port/path/to/repo.git". Git fetcher clones such remote Jan 04 14:19:31 repository into "${DL_DIR}/git2/host:port.path.to.repo.git". However, Jan 04 14:19:32 when clonging from ${DL_DIR}/git2/host:port.path.to.repo.git into Jan 04 14:20:35 ant_work, I have got error while running bitbake Jan 04 14:20:38 ERROR: Required build target 'metfsx86' has no buildable providers. Missing or unbuildable dependency chain was: ['metfsx86', 'fuse-native'] Jan 04 14:20:49 my application depends on fuse and libgcrypt Jan 04 14:21:10 I use in my board by cross compiling with metfs bb Jan 04 14:21:25 and also need to compile native for using on host Jan 04 14:21:46 I renamed metfs bb and add "inherit native" line Jan 04 14:22:00 then update DEPENDS as "fuse-native libgcrpyt-native" Jan 04 14:22:21 Do I miss something? Jan 04 14:24:04 I think fuse is only in meta-oe layer Jan 04 14:25:15 yes, and even there there isn't providers for fuse-native Jan 04 14:25:54 yes, I searched oe recipes and there is not any recipes DEPENDS on fuse-native Jan 04 14:29:17 you can install it on your host and add an ASSUME_PROVIDED Jan 04 14:30:18 hm ok, thanks Jan 04 15:01:08 gy and gm all Jan 04 15:08:48 hey likewise, hny to you too! Jan 04 15:46:49 how can i use external toolchains with oe-core? Jan 04 16:55:07 is there an easy way to force a kernel rebuild each time? Jan 04 16:55:23 i was thinking about putting the data in the PR Jan 04 16:55:36 PR_pn-linux = `date` Jan 04 16:56:09 a better way is to always mark the do_compile step as needing to be run Jan 04 16:56:20 so we don't make a whole new folder Jan 04 17:17:57 scoutcamper: around ? Jan 04 17:19:28 msm, are you using an external local source tree, or doing the fetch/unpack/patch? regardless, do_compile[nostamp] = 1 is how you'd do what you described Jan 04 17:19:29 hmm Jan 04 17:22:25 kergoth: i think that's what im looking for Jan 04 17:22:45 kergoth: how would that go into a conf/local.conf file? Jan 04 17:23:11 require conf/nostamp.inc, then do it in anonymous python Jan 04 17:23:28 flags don't traverse overrides right now, as it's not entirely clear what hte behavior would be Jan 04 17:25:17 Jin^eLD: I am in pacific time zone Jan 04 17:26:05 nitink1: hi :) Jan 04 17:26:12 kergoth: hmmm, ok thanks Jan 04 17:26:15 nitink1: I found a thread on the ml regarding eglibc locale Jan 04 17:26:33 you were planning to have a look at this, I guess you did not have the chance yet? Jan 04 17:26:48 let me find the link so you know what I am talking about... Jan 04 17:26:57 maybe you can help me to solve this issue Jan 04 17:29:15 nitink1: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-August/008181.html Jan 04 17:31:21 I am not really sure how this part in OE works, but basically the problem is that someone or something adds "Provides: eglibc-binary-localedata-en-us" to locale-base-en-us Jan 04 17:31:39 which makes it impossible to install or pull in the eglibc-binary-localedata-en-us package into the rootfs Jan 04 17:31:49 and without it gettext is broken... Jan 04 17:31:56 any hints for me? :> Jan 04 17:34:30 yeah, that is just bogus Jan 04 17:34:48 it was apparently introduced in commit 561d8754, which I think is the same point that the other breakage happened. Jan 04 17:35:02 I think you should just delete that RPROVIDES again. Jan 04 17:35:58 hi Jun Jan 04 17:36:04 sorry Jin Jan 04 17:37:57 pb_: where exactly is that bogus RPROVIDES? in the bbclass? I tried to look through this all eglibc stuff but got lost somehow Jan 04 17:38:31 Jin, I will need to look into it Jan 04 17:38:34 yeah, it's in libc-package.bbclass Jan 04 17:39:04 in output_locale_binary_rdepends() iirc Jan 04 17:39:37 Jin: so you are saying gettext can not be put in images ? Jan 04 17:40:15 nitink1: no, gettext itself can be put in images, but you can't set stuff to say, en_US.UTF-8 Jan 04 17:40:30 because eglibc-binary-localedata-en-us is not in the image Jan 04 17:40:58 and eglibc-binary-localedata-en-us can not be put into the image because opkg things it's already covered by locale-base-en-us Jan 04 17:41:10 and that is because locale-base-en-us has this bogus provides Jan 04 17:41:14 Jin, Can you open an bug here: http://bugzilla.pokylinux.org and please provide the steps to reproduce the issue Jan 04 17:41:39 nitink1: ok Jan 04 17:42:25 Jin: thanks, will take it on bugzilla then Jan 04 17:42:53 thx Jan 04 17:45:38 nitink1: do I file it against meta-recipes / core? Jan 04 17:45:55 Jun: yes Jan 04 17:46:08 sorry again, Jin: yes Jan 04 17:46:10 :) Jan 04 17:46:21 :) Jan 04 18:03:20 How can I get bitbake to spit out a python backtrace when it dies executing python code? Jan 04 18:16:20 Russ: it does do that by default Jan 04 18:17:18 it just prints the last line of it Jan 04 18:22:32 eg, ...ERROR: Exception: I'm looking at what better_exec in bitbake/lib/bb/utils.py does Jan 04 18:23:16 it looks through the trackback until it gets to the end, and just prints that Jan 04 18:28:09 its been a desire to improve bitbake's error recovery and reporting Jan 04 18:28:35 nitink1: http://bugzilla.pokylinux.org/show_bug.cgi?id=1874 Jan 04 18:28:38 we've come a long way, but still not where it needs to be Jan 04 18:28:47 I guess I should have come up with a better summary though :P Jan 04 18:29:17 It'd be nice if print_exception was used to dump the backtrack somewhere Jan 04 18:29:23 aside: this is one area where oe-lite's new parser is lovely, the line numbers are apparently retained for python code in the metadata, so the full traceback is more useful Jan 04 18:30:00 hmmm Jan 04 18:30:03 Russ, the difficult thing is, determining when to show it and when not to show it, sometimes a user wants it, sometimes they don't, depends on context and the exception in question. i agree, it'd be nice if all exception tracebacks went to a log regardless of what the UI wants Jan 04 18:30:09 kergoth: did you buy the chair ? Jan 04 18:30:12 khem, yep Jan 04 18:30:35 that's why I said at least dump it somewhere, like in temp/ Jan 04 18:31:27 Tartarus: you pinged me yesterday around this time, I'm available the next few hrs. Jan 04 18:31:51 Russ: is this a python task, anonymous python, or an event handler? Jan 04 18:31:57 or inline python? Jan 04 18:32:02 all 4 need to be handled sanely :\ Jan 04 18:32:33 patch.py Jan 04 18:35:17 Jin: saw the bug Jan 04 18:38:12 nitink1: does it make sense or did I miss anything (i.e. something unclear?) Jan 04 18:38:41 eFfeM, did I go crazy, push your net-snmp change to the maintenance branch and then forget to reply to the ML? Jan 04 18:38:51 Jin: I think it is good for now to get started, if I need more I will respond on the bugzilla Jan 04 18:39:01 thanks! Jan 04 18:39:11 let me know if I can help to speed up the process Jan 04 18:40:09 Tartarus: not sure whether you replied, but I noticed it was pushed, thanks for that Jan 04 18:41:21 So neither of us are 100% sure how it ended up in there, OK :) Jan 04 18:41:27 Musta just forgot to send the email Jan 04 18:41:52 no problem Jan 04 18:42:50 Tartarus: did you see my mail on binutils? you pushed 2.20.1a to master, but not not maintenance and 2.20.1 does fetch with a crc error (it became a symlink to 2.20.1a on the gnu site) Jan 04 18:43:12 yeah, kicking that again is on my TODO list Jan 04 18:43:20 Need to finish my slides for SCaLE first tho Jan 04 18:44:10 np, I know you're busy (so am I) Jan 04 18:45:25 Tartarus: can you look at my u-boot patch for meta-ti and comment ? Jan 04 18:45:44 Tartarus: https://lists.yoctoproject.org/pipermail/meta-ti/2011-December/000275.html Jan 04 18:45:45 which ml? Jan 04 18:45:56 hm Jan 04 18:45:57 meta-ti ml Jan 04 18:46:24 koen wants you to review it Jan 04 18:46:51 k Jan 04 18:47:19 thx Jan 04 19:16:25 kergoth, I was trying to get patch.bbclass and patch.py to do a quilt patch series, it looks like it has all the functionality, but somewhere, someone is getting an EISDIR and throwing an exception Jan 04 19:16:48 eg, "file://patch_path;apply=true" Jan 04 19:25:11 hmmm iMX.6 Jan 04 19:35:35 khem, i am arround now Jan 04 19:43:46 is there something special about how libgcc behaves in an DEPENDS? Jan 04 19:43:57 im doing DEPENDS += libgcc Jan 04 19:44:12 but, its not listed in the RPM deps.. and not being pulled into the rfs Jan 04 19:44:25 there is an RPM with the files I need installed called libgcc1 Jan 04 19:46:13 DEPENDS is only used for building.. Jan 04 19:46:35 RDEPENDS_pn is used for setting run-time dependencies for a package split Jan 04 19:47:40 right Jan 04 19:48:00 I tried without the "_pn" but I've done both Jan 04 19:48:06 and nothing from libgcc is getting pulled in Jan 04 19:48:22 naming wise.. DEPENDS needs to match the recipe name.. while RDEPENDS_ needs to match the split name (before being munged by the debian class..) Jan 04 19:48:48 but libgcc should be an automatic dependency that is brought in as part of hte libc.. Jan 04 19:49:46 well Jan 04 19:50:01 my minimal rfs does not have any libgcc libraries Jan 04 19:50:08 but im looking to add this one: tmp/deploy/rpm/ppce500mc/libgcc1-4.6.1+svnr175454-r12.ppce500mc.rpm Jan 04 19:50:14 its built fine Jan 04 19:50:35 something has to depend on libgcc.so Jan 04 19:50:46 if it doesn't then you have a dependency cacluation/detection problem Jan 04 19:50:57 running: rpm -qlp -R tmp/deploy/rpm/ppce500mc/libgcc1-4.6.1+svnr175454-r12.ppce500mc.rpm Jan 04 19:51:01 does not list libgcc in the requirements Jan 04 19:51:10 while the other DEPENDS are there like libxml, libz etc Jan 04 19:51:30 err Jan 04 19:51:33 you want rpm -qp --provides if you are scanning libgcc1 Jan 04 19:51:41 im not scanning libgcc Jan 04 19:51:47 what is the exact requirement ending up in libxml that isn't being met? Jan 04 19:51:52 i meant to list my target packages *which* depends on libgcc Jan 04 19:52:07 its not libxml Jan 04 19:52:14 its a internal package Jan 04 19:52:27 my internal package depends on libxml, libz, and I need to add libgcc Jan 04 19:54:45 on my random MIPS based system this is what I end up with: Jan 04 19:54:49 libgcc1 provides: Jan 04 19:54:54 libgcc1 libgcc_s.so.1(GCC_3.4.2) Jan 04 19:54:54 libgcc1 libgcc_s.so.1(GLIBC_2.0) Jan 04 19:54:58 (and a host of others) Jan 04 19:55:04 libstdc++6 requires: Jan 04 19:55:11 libstdc++6 libgcc_s.so.1(GLIBC_2.0) Jan 04 19:55:17 so the depednency is met.. this should be automatic Jan 04 19:55:44 if your internal component required libgcc.so -- then it should have a SONAME requirement, which should be found by the dependency scanning system Jan 04 19:56:58 Dynamic section at offset 0x114 contains 29 entries: Jan 04 19:56:58 Tag Type Name/Value Jan 04 19:56:58 0x00000001 (NEEDED) Shared library: [libm.so.6] Jan 04 19:56:58 0x00000001 (NEEDED) Shared library: [libc.so.6] Jan 04 19:56:58 0x00000001 (NEEDED) Shared library: [ld.so.1] Jan 04 19:56:59 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] Jan 04 19:57:13 fray: right Jan 04 19:57:15 (thats from libstdc++.so.6 on this machine) Jan 04 19:57:20 fray: except it's not a soname requirement? Jan 04 19:57:26 fray: im not sure why though Jan 04 19:57:29 yes it is.. it's in the NEEDED Jan 04 19:57:44 if it's not in NEEDED, then well it isn't needed -- or it should be brought in by another (needed) component Jan 04 19:57:50 what if it's dynamically loaded or something? Jan 04 19:58:15 Then it would be done by dlopen -- which is possible.. that is where you have to manually specify your shared library dependencies Jan 04 19:59:42 I believe libgcc is the PN you need to require.. so RDEPENDS_splitpn += libgcc Jan 04 19:59:57 libgcc will be translated to libgcc1 by the debian.class munging Jan 04 20:01:13 for rpm packages, we have additional versioned dependencies on a per-file basis implemented -- none of the other packaging mechanisms have that though.. which is why it has to be specified in that way on the RDEPENDS_pn.. Jan 04 20:01:39 on a desktop RPM based system you'd actually want to specify the exact soname you require by any dlopen actions... but you can't do that in bitbake -- yet Jan 04 20:02:07 at some point we need to figure out how to roll up the per-file dependencies into package level dependencies that can be added to deb and ipkg packages Jan 04 20:02:45 (but it's somewhat questionable as to the benefits of doing that for folks already familiar w/ ipkg and deb packages.. for RPM it was a necessity) Jan 04 20:07:23 fray: ok im double checking my RDEPENDS_${PN} then Jan 04 20:16:29 fray: ok - the RDEPENDS_${PN} was my issuue Jan 04 20:16:49 libgcc1 is not listed as a requirement on the rpm for the recipe im working with Jan 04 20:16:56 is NOW* listed Jan 04 20:17:15 and it's in the rfs =) Jan 04 20:19:22 It does seem like a problem though that you have to specify libgcc as a manual requirement.. Jan 04 20:19:29 it's very odd to see that one dlopened.. Jan 04 20:49:35 what's the purpose of contrib git for both oe-core and meta-oe? Jan 04 21:15:57 xxiao: relevance Jan 04 21:16:27 xxiao: we could just have one though calle oe-contrib or some such Jan 04 22:32:50 fray: regarding libgcc from earlier… yes it's weird Jan 04 22:34:15 whats the issue with libgcc ? Jan 04 22:36:46 khem: hello there Jan 04 22:41:38 ant____: hi Jan 04 22:41:53 ant____: your tail has grown in 2012 :) Jan 04 22:42:10 heh, like gray hairs ;) Jan 04 22:42:36 there use to be only one underscore in your nick Jan 04 22:43:08 khem: about gcc, I was wondering why do we keep a gcc_4.6 in meta-oe? Jan 04 22:43:19 just to test linaro patches? Jan 04 22:44:33 more than that Jan 04 22:44:45 it makes code generation for arm better Jan 04 22:44:50 atleast for armv7 Jan 04 22:45:05 better than oe-core's gcc_4.6? Jan 04 22:45:07 and or-core does not favor one arch over others Jan 04 22:45:13 yes Jan 04 22:45:19 ok, I see Jan 04 22:45:30 there are some fixes that went into oe-core too from meta-oe Jan 04 22:45:38 since yocto supports beagleboard Jan 04 22:45:48 and these fixes were absolutely needed Jan 04 22:45:56 but goodies are not taken there Jan 04 22:46:04 unless they are really needed Jan 04 22:46:53 all fine but this is partially bad if one builds with oe-core + bsp only Jan 04 22:46:56 scoutcamper: are you around ? Jan 04 22:47:04 khem, yep Jan 04 22:53:10 ant____: generally if you have arm board add meta-oe to layers Jan 04 22:54:14 khem: sorry to inform you that apart toolchain there are serious drawbacks Jan 04 22:55:13 ant____: interesting dichotomy Jan 04 22:55:14 I'm still struggling with udev and xserver-nodm-init 'crosstalk' Jan 04 22:56:10 and by the way pls note we have still kernel.bbclass in meta-oe (and this is even not parsed by default if you list meta-oe after oe-core in your bblayers) Jan 04 22:57:50 hmmm Jan 04 22:57:57 how does it work with angstrom ? Jan 04 22:58:15 that's the point, meta-oe seems only testewd/working with A. Jan 04 22:58:34 I build bare oe-core + bsp Jan 04 22:58:40 no distro Jan 04 22:58:49 hmmm Jan 04 22:59:01 I have slugos using oe-core + meta-oe Jan 04 22:59:08 and meta-micro uses it too Jan 04 22:59:12 so it should work Jan 04 22:59:21 heh, you don't have X issues Jan 04 22:59:45 and udev won't try to write the cache on RO root on boot Jan 04 23:00:08 by default Jan 04 23:00:23 it seems all is magically working with A. and systemd Jan 04 23:00:51 but my point is meta-oe should complement oe-core and not being a distro-layer Jan 04 23:02:29 yes indeed but if we have more distros using X Jan 04 23:02:34 how does it go with SHR Jan 04 23:04:09 no idea, never built Jan 04 23:04:59 I can state that core-image-sato boots when compiled oe-core + bsp only Jan 04 23:05:28 the active test case is angstrom Jan 04 23:05:41 we need more people using more combinations actively Jan 04 23:05:46 and testing beyond just building Jan 04 23:05:50 (I have to copy a couple of things from meta-oe, though, like xfbdev driver) Jan 04 23:06:28 my immediate issue is xserver-nodm-init and Rdependencies Jan 04 23:06:47 udev is worked on in oe-core and meybe will be unified soon Jan 04 23:06:57 (fingers crossed) Jan 04 23:07:51 yes I agree we need more distro's to excercise meta-oe Jan 04 23:08:13 sorry I disagree Jan 04 23:08:21 first should work distroless Jan 04 23:08:36 work = build+runtime Jan 04 23:08:47 imho Jan 04 23:09:07 distroless is the same thing Jan 04 23:09:13 ant____: yes thats what it is Jan 04 23:09:17 that case should also be exercised Jan 04 23:09:29 we dont know if its distroless unless someone finds something thats not Jan 04 23:09:52 well, I end up removing files from meta-oe layer to 'fix' the things :/ Jan 04 23:10:45 ant____: you should bring it up Jan 04 23:10:51 and we should solve it Jan 04 23:11:00 I did, I'll repeat Jan 04 23:11:04 you have to tell us what files :) Jan 04 23:11:09 in email :) Jan 04 23:11:10 like if something is distro specific then it should move to meta- Jan 04 23:11:11 just look at the cruft in http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-graphics/xserver-common/xserver-common_1.34.bb Jan 04 23:11:12 more eyes Jan 04 23:11:28 this is bsp specific cruft by the way... Jan 04 23:11:50 all those patches Jan 04 23:12:13 jama was consolidating those into oe-core IIRC Jan 04 23:12:23 hmm... Jan 04 23:12:43 first issue here is amisnaming: xserver-common vs. x11-common Jan 04 23:12:53 meta-oe vs. oe-core Jan 04 23:13:14 then the runtime deps Jan 04 23:13:28 ..and I'm not an expert wrt X Jan 04 23:13:35 yes there are differences Jan 04 23:13:42 I think we are getting them sorted Jan 04 23:13:46 so I can't easily judge which approach is best Jan 04 23:13:47 slowly but surely **** ENDING LOGGING AT Thu Jan 05 02:59:57 2012