**** BEGIN LOGGING AT Wed Jan 16 02:59:59 2013 Jan 16 03:03:31 from which recipe file tell yocto where to fetch the igb source code Jan 16 06:30:21 <_Lucretia_> hi, I need to add to a variable that gnatmake looks for GPR_PROJECT_PATH, i each of my library projects I want to add something like GPR_PROJECT_PATH .= "${D}${libdir}/ada/${PN}:" so each recipe adds itself to the variable so we cna use them later on easily. Jan 16 06:30:26 <_Lucretia_> how do I do that? Jan 16 08:48:29 good morning Jan 16 09:30:23 morning all Jan 16 09:43:38 morning Jan 16 11:33:19 hello everyone! Jan 16 11:34:05 to add packages in my project all that i have to do is to set IMAGE_FEATURES_append := " package", right? Jan 16 11:34:54 nom features != packages Jan 16 11:35:01 "no," even Jan 16 11:35:20 if your image inherits core-image, then CORE_IMAGE_EXTRA_INSTALL is there to use Jan 16 11:35:29 i.e. CORE_IMAGE_EXTRA_INSTALL += "weston" Jan 16 11:35:46 if i want to add ssh i should put " ssh-server-openssh". but what if i want to add a c compiler, apache stuff and php? what package names should i use? Jan 16 11:35:59 if you want to add a toolchain, add tools-sdk to the image features Jan 16 11:36:07 hm Jan 16 11:36:35 then you get gcc and everything else you actually need - bintutils, libc headers, make etc. Jan 16 11:36:54 for apache and php, you'll have to look up what the packages are called and if there are any meta packages Jan 16 11:36:59 i don't use the web stuff Jan 16 11:38:55 rburton: okok, thx dude! so the package names for gcc are the same for my desktop, right? Jan 16 11:39:12 gbrennon: not always Jan 16 11:39:44 you'll have to look at the recipes Jan 16 11:41:02 rburton: at the recipes located in my project directory, right? okok thank u dude. where can i see all the packages that gcc needs for this kinds of build(embedded)? Jan 16 11:43:02 gbrennon: as i said, if you want to compile in the image, just use the tools-sdk image feature. much easier. Jan 16 11:43:30 oh, now i get it. okok thank u dude!! Jan 16 11:44:04 are u working in some kind of project with yocto today? what board do u use? since when are u using this project? Jan 16 11:45:26 gbrennon: i work on yocto for intel Jan 16 11:45:51 wow nice Jan 16 11:46:56 in which country do u live? im from brazil and im initiating with embedded os and arm stuff. im student of engineering and found a imx28 in my job hahaha Jan 16 11:47:35 UK Jan 16 12:09:48 rburton: i have +1 question. to build again my image i have to ". ./source-environment" again? cause i'm executting bitbake core-image-minimal again and it says the command doesn't exist :( Jan 16 12:10:04 gbrennon: only if you closed the terminal Jan 16 12:10:17 hm Jan 16 12:10:21 ok Jan 16 12:10:29 that sets the environment for the current terminal. closing it will wipe it. Jan 16 12:10:45 so i have to add all the ambient variable again or only ". ./source-environment build" again? Jan 16 12:11:11 if you've closed the terminal, just re-run . ./source... again Jan 16 12:11:33 okok, thx Jan 16 12:12:55 rburton: thx a lot and i'm sorry for the disturbing. Jan 16 12:13:20 np Jan 16 12:53:13 gbrennon: Hi :-) I am Brazilian as well Jan 16 12:53:54 otavio: sério? mora onde? Jan 16 12:54:07 gbrennon: you should start looking at the Yocto documentation as a lot of common tasks are properly documented there. Jan 16 12:54:14 gbrennon: I live in Pelotas, RS Jan 16 12:54:30 gbrennon: keep talking in English as a respect to other people in the room :-) Jan 16 12:55:13 gbrennon: I am one of maintainers of meta-fsl-arm; so if you have problems using mx28evk let me know. Jan 16 12:55:49 otavio: okok :) i'm reading about the documentation and looking for some help as i have some dificulties on solving problems. now i'm reading more about adding packages causa i'm "shy" about asking again the rburton about this haha Jan 16 12:56:35 gbrennon: yes; please read the docs. They are very good and has a high quality. Jan 16 12:56:58 gbrennon: you may still need help in some specific thing later but basics are well covered there. Jan 16 12:57:13 rburton: I did not test wayland yet sorry Jan 16 12:57:14 otavio: u are on of the maintainers of meta-fsl-arm? wow, nice. how do you contribute with this? since when do u use yocto project and contribute with this one? Jan 16 12:57:16 rburton: ;-) Jan 16 12:58:11 gbrennon: I have a company which gives consulting and BSP services; we've been working with Freescale to support their iMX platforms in Yocto and meta-fsl-arm the result of it. Jan 16 12:58:22 gbrennon: most common boards are supported there. Jan 16 12:58:45 (out for 2hs) Jan 16 12:59:07 otavio: np Jan 16 13:00:01 otavio: nice! how do u got that kind of contact with Freescale? Jan 16 13:16:08 hello all, could someone please give me a hint of how to create a root user in a simple core-image-base ? I have problems loading drivers + firmwares most likely because the fact that I'm loging in on pandaboard as root but i doubt this is granting a full access.. I'm a bit lost in this subject. Jan 16 13:24:45 pdv: root has full access, by definition Jan 16 13:31:51 rburton: I came down long way to this possibility as Im unable to find any more reason for the original issue I'm facing with... When I modprobe a wifi driver it is can not find the /lib/firmware/... folder which contains the firmware itself. Since everything is clearly in place in that regard, I was suspecting that the default user privileges are messed up. last option is a trouble with udev. Must be something very obvious Jan 16 13:59:07 hey rburton, can u help me again? in the documentation talks about the package "apps-console-core" that has ssh daemon, port map, bla bla. i've compiled my img with tools-sdk and apps-console-core but the 2nd one didnt work. tools-sdk compiled ok, but apps-console didnt Jan 16 14:02:19 gbrennon: please ensure the documentation version you are reading matches the version of the build system you are using Jan 16 14:02:38 with the latest stable release apps-console-core shouldn't be used Jan 16 14:11:36 gbrennon: Well; long history ... Jan 16 14:15:22 Do someone have any clue about this build failure of avahi? http://autobuilder.yoctoproject.org:8010/builders/nightly-fsl-arm/builds/29/steps/shell_71/logs/stdio Jan 16 14:26:57 otavio: where in my directory tree can i look which pakages can i use? i want the "correct" reference for the "apps-console-core" Jan 16 14:28:00 gbrennon: you can check what the image feature does, in the poky/meta/classes/core-image.bbclass and than check the recipes it includes Jan 16 14:28:59 gbrennon: also see the documentation for IMAGE_FEATURES in the reference manual Jan 16 14:31:06 otavio: okok thanks dude! Jan 16 14:31:27 bluelightning: i'll look at this section Jan 16 14:32:13 bluelightning: the poky handbook from the poky website is a good reference or should i use only the yocto project reference and the docs in my directory tree? Jan 16 14:35:11 gbrennon: I would strongly recommend using the documentation on the yocto project website or in the source tree Jan 16 14:36:28 the manual on the poky website is very old Jan 16 14:37:05 bluelightning: shouldn't pokylinux redirect to yocto these days? Jan 16 14:37:49 I think that would be an improvement yes Jan 16 16:26:44 Jefro, ping Jan 16 16:28:01 Jefro1, ping Jan 16 16:31:24 bluelightning: I had a patch here http://patchwork.openembedded.org/patch/41951/ Jan 16 16:31:33 bluelightning: for meta-opie Jan 16 16:31:46 without this parsing breaks for angstrom Jan 16 16:32:20 can you take a look and install it if ok Jan 16 16:37:08 khem: the trouble is there is a bbclass file in meta-opie that ideally I want to override the one in OE-Core Jan 16 16:37:50 sdl.bbclass that is. not that it's of much use right now since libsdl-qpe isn't really working... Jan 16 16:45:44 bluelightning: hmm so how you laid out the bblayers.conf can fix it too Jan 16 16:45:57 bluelightning: problem is immediate expansion doesnt work anymore Jan 16 16:46:04 and there is exception thrown Jan 16 16:55:11 khem: I guess your patch with =. and : moved to the end for BBPATH would satisfy everyone Jan 16 17:04:36 hmm, should fix some of these cases where a recipe isn't named matching the upstream project name (e.g. libnewt recipe for newt) Jan 16 17:05:04 davest, http://www.dtic.mil/dtic/tr/fulltext/u2/a275216.pdf Jan 16 18:15:31 zeddii, has any thought been given to moving multi-dtb.inc into oe-core? Jan 16 18:24:35 Hmm, i'd kind of like to distinguish between 'not wanting libx11 in any shape or form to ever be built' and 'i'd prefer that things that *could* depend on x11, but don't need to, to not do so' Jan 16 18:24:55 i think there'd be value in being able to turn on the latter but still have an option of building, say, core-image-sato, or fleshing out a feed Jan 16 18:25:22 that is, i'd like it if the x11 libs didn't skip themselves when x11 wasn't in DISTRO_FEATURES, and instead a person could use PNBLACKLIST if they care that strongly Jan 16 18:27:58 hmm, and just because i'd prefer to reduce x11 deps doesn't mean i want gtk+-directfb, either.. Jan 16 18:28:04 * kergoth thinks we need to untangle this a bit Jan 16 18:57:41 kergoth: urgh, does gtk turn "not x11" into "use directfb"? Jan 16 19:07:33 hi, I cannot find the info anywhere, but is there a way to set a new variable which get seen by the actual commands in yocto? Jan 16 19:10:10 rburton: not directly, but i think at least some versions only support directfb or x11, and it disables the latter.. given directfb is also controlled by a feature, i suspect the build would fail entirely without either in distro features.. will have to confirm that hypothesis, though.. Jan 16 19:10:15 heh Jan 16 19:10:32 PortaLu: by 'actual commands' you mean tasks? Jan 16 19:10:41 PortaLu: or tools run by the tasks? Jan 16 19:10:51 PortaLu: likely you just want to mark the variables as exported with the 'export' command Jan 16 19:10:54 grep around for examples Jan 16 19:11:24 commands that are run by tasks, like compilers Jan 16 19:11:52 I tried export, bitbake then fails to parse the scripts Jan 16 19:12:03 then your syntax wasn't correct Jan 16 19:12:06 export works just fine Jan 16 19:12:13 its' used all over the metadata Jan 16 19:12:17 grep for it, you'll see Jan 16 19:14:11 PortaLu: MYVAR[export]="1" will cause external processes to get a $MYVAR environment variable matching the recipe. Jan 16 19:15:34 and how do you append to it? MYVAR[export] += "something" ? Jan 16 19:15:45 or .= "something" even Jan 16 19:16:25 No, "[export]" is a flag set. All it does is add MYVAR to the environment. You set the *value* of MYVAR the same way you do any variable. += will append to it with an intervening space, etc... Jan 16 19:17:55 ok, so I set the var as MYVAR[export]="1" to make it available to the env, then use MYVAR .= ":path" to add to it? Jan 16 19:19:15 Pretty much Jan 16 19:20:04 trying it now Jan 16 19:20:22 ok, here is what i've done Jan 16 19:20:45 in my meta-ada/conf/layer.conf I have GPR_PROJECT_PATH[export] = "1" Jan 16 19:21:30 then in my meta-ada/recipes-test/libhello/libhello.bb file (which is a test lib), I set GPR_PROJECT_PATH .= "${D}${libdir}/ada/${PN}:" Jan 16 19:21:55 $ bitbake -e hello|grep GPR Jan 16 19:21:55 # GPR_PROJECT_PATH=None Jan 16 19:23:06 andyross: the idea is this - for each library in the layer, add the project directory path to that variable so that any project that uses gnatmake get access to the libs easily Jan 16 19:24:20 The .= is appending, but there's no leading colon to separate. Use =. to prepend, or put the colon on the other side. Beyond that I dont' see anything obviously wrong Jan 16 19:24:44 apart from the above result from -e Jan 16 19:25:48 Honestly I don't know what -e is supposed to do. Try a devshell in a relevant recipe Jan 16 19:26:23 ahh Jan 16 19:27:31 PortaLu: export MYVAR Jan 16 19:27:32 done. Jan 16 19:27:44 layer.conf really isn't where that belongs Jan 16 19:27:49 *really* isn't where that belongs Jan 16 19:28:06 Heh, had no idea there was an explicit syntax for export. Fun. Jan 16 19:28:44 it's always been there. the flag is what's set under the hood, but best not to rely on that where it isn't necessary Jan 16 19:29:03 if you guys haven't yet read bitbake.conf, highly recommended Jan 16 19:30:17 ok, thanks Jan 16 19:30:20 it's working now Jan 16 19:32:24 one thing tho, is it posisble to set it only after the lib project has built and installed? I spose it would be best to use a _post?? Jan 16 19:33:02 I mean, set it so that even if part way through the build it's only set if that library has built Jan 16 20:07:09 If I'm defining a new bsp, and I don't want to run X, should I omit the XSERVER variable, set it to blank, or ... ? Jan 16 20:07:11 I'm looking to propose a patch for an oe-core .bb file. There are some portions of a library not built (and of course I need them) with the reason being they didn't compile for a certain processor. I think the problem has been fixed in the library (a LONG time ago), but the restriction is still in place. What different machines should I test against prior to suggesting the patch? Jan 16 20:08:09 similarly, if I don't want a kernel, is there a way to specify that I want to omit that? (I'm looking to build a rootfs for a lxc vm) Jan 16 20:08:15 adalton: whether X is run or not is defined by the image produced. So amke sure the images in your BSP do not have X as a program and you are good. Jan 16 20:08:34 blloyd_: cool -- thanks Jan 16 20:10:48 blloyd_: what library, out of curiosity? Jan 16 20:11:48 boost. :) Jan 16 20:13:52 yikes :) Jan 16 20:14:03 the problems I think are from way back in 1.21 series of boost, and that is ANCIENT. We are using 1.51 in danny, and I 1.49 in denzil. Jan 16 20:14:41 yikes I'm using boost or yikes OE mangles the boost build? Jan 16 20:16:14 both, actually Jan 16 20:16:27 you don't like boost? Jan 16 20:20:53 and here is another one. Is there a nice way to optionally depend on ICU? Such as turning ICU on/off for distro and or machine? I'm not the most familiar with ICU overhead, but understand there is some, but libraries like boost really prefer to have it (disabled in OE ver) Jan 16 20:32:16 as far as omitting a kernel, could I specify my preferred provided for the kernel to be linux-dummy? Is that the indent of linux-dummy? Jan 16 20:32:22 s/indent/intent/ Jan 16 20:35:27 and is there a way to specify that I want glibc as opposed to uclibc (or whatever the default implementation is)? I'm not building for an embedded platform. Jan 16 20:36:38 eglibc is default, and is the default in many desktop distros as well Jan 16 20:36:42 so there's no need for you to specify anything Jan 16 20:36:58 TCLIBC is the variable used to control libc selection, though Jan 16 20:37:43 ah, ok Jan 16 20:37:44 thanks Jan 16 20:42:42 anyone know if there are active activites for cleaning up the yocto-kernel config fragments? 16 warnings from building a kernel (and only 1 is because of my own addition). Jan 16 20:48:24 kergoth: my goal is to build a rootfs for an lxc vm. My concern is that I might need to get a libc implementation that will be compatible with the host's kernel, and I figured that'd be easier with glibc Jan 16 20:49:13 that's why I'd like to find a way to say "I don't want a kernel" since I'll get the kernel from the host Jan 16 20:53:56 otherwise I guess I can create a dummy kernel that does nothing and configure it to use that Jan 16 21:08:41 ah, looks like linux-dummy will do trick Jan 16 21:09:02 adalton, right, that Jan 16 21:10:06 I know yocto has a bug tracking tool, but a quick check of website didn't have a reference to it. Where is the bug tracker? For those dealing with the web, where is it referenced (and should it be easier to find)? Jan 16 21:11:55 bugzilla.yoctoproject.org Jan 16 21:14:35 ok, I'm still stuck on this variable setting problem, well it's setting inside the libhello.bb file, but inside hello.bb which DEPENDS on libhello, it cannot be seen Jan 16 21:14:44 well, the -e flag is not showing it Jan 16 21:15:54 a link for which can be found by starting at www.yoctoproject.org, clicking the big yellow "Tools + Resources", then "Bugs" in the link list on the left. Not too hard to find, I guess. However, I dare anyone (who doesn't already know where it is) to find a link to the git server in less than five minutes.... Jan 16 21:18:07 PortaLu: it doesn't work like that--DEPENDS doesn't bring in the depended-on .bb's variables Jan 16 21:19:51 PortaLu: read documentation for / find examples of the include, require, and inherit keywords, one of them is probably appropriate Jan 16 21:25:01 well, I need to add to that variable from many packages, and then use them in final packages, so the only thing I can think of is a class with the initial variable defined and exported and then inherited in each library Jan 16 21:32:52 PortaLu: it _may_ also make sense to use require Jan 16 21:36:03 k Jan 16 21:36:04 thanks Jan 16 21:50:54 so I'm trying to use the linux-dummy kernel, and now I get a problem that busybox depends on fbset-modes; but I don't see where there dep comes in Jan 16 21:51:25 adalton, you mean you don't see what provides it? Jan 16 21:51:33 ERROR: Nothing RPROVIDES 'fbset-modes' (but .../meta/recipes-core/busybox/busybox_1.20.2.bb RDEPENDS on or otherwise requires it) Jan 16 21:51:33 adalton, have you grepped the sources? Jan 16 21:52:05 no, I don't see anything the busybox recipes that express that dependency Jan 16 21:52:37 adalton: what layers are you using? Jan 16 21:53:12 meta, meta-yocto, and meta-meentor Jan 16 21:53:26 plus one I'm creating for lxc Jan 16 21:53:37 s/meentor/mentor/ Jan 16 21:54:02 meta-mentor requires meta-oe unless you mask out a couple things, like the busybox bbappend :) you can remove it manually, or set BBMASK to mask it out Jan 16 21:54:14 i should document that in the readme, if it isn't already.. Jan 16 21:54:19 actually, i thoguht i already put that info there Jan 16 21:55:02 yeah; it's there. I had it and removed it when I was trimming out some things Jan 16 21:55:36 yep, that's the busybox I'm picking up Jan 16 21:55:50 let me remove that layer and try again -- thanks Jan 16 21:56:13 i've thought about splitting out a second layer for the meta-oe bits, but there aren't very many, so haven't bothered Jan 16 21:56:14 np Jan 16 21:56:31 odd though that it gave me the path to the busyboy recipe in /meta/ Jan 16 21:57:14 no, thats how appends work, they basically concatenate Jan 16 21:58:01 ah, makes sense Jan 16 21:58:44 ideally, more information would be retained after parsing about the files/linenumbers, but currently that's not the case :\ Jan 16 21:59:01 hmm. the git binaries in my sysroot are not being removed when I cleanall on git-native. I may just not have noticed this before I suppose Jan 16 22:00:46 zeddii: ouch, even with 3.8-rc3 I get /yaffs_vfs.c:2289:4: error: 'struct super_block' has no member named 's_dirt' Jan 16 22:01:04 not with vanilla, it's some yocto feature Jan 16 22:01:04 hmmm. they've changed an interface .. again. I'll have a look. Jan 16 22:01:23 yah. there's a yaffs2 fs floating around. I keep porting and maintaining it. Jan 16 22:01:58 I remember doing that for lzma in 2.6.3x kernels :) Jan 16 22:05:41 is there a way to say that I want a specific version of a recipe? Jan 16 22:06:10 say it's picking up version Z but I want version X, which is older than Z Jan 16 22:07:00 there's no real support for version specific DEPENDS Jan 16 22:08:43 hum.. the issue I'm trying to address is that I'm building a rootfs for an lxc vm that will be hosted on a 2.6.27 kernel. I wanted my kernel headers to more closely match that kernel version. Jan 16 22:11:01 I guess I could just blow away all the newer versions, but that doesn't seem like a great idea :) Jan 16 22:11:47 so use a 2.6.27 kernel and point at STAGING_KERNEL_DIR Jan 16 22:12:45 yeah, but I'm using the linux-dummy kernel recipe since lxc uses the host's kernel Jan 16 22:14:05 I guess I could create a dummy-like recipe that does the extract, but not the build/install and do the STAGING_KERNEL_DIR business Jan 16 22:19:50 if you aren't using a proper kernel recipe, just point at /lib/modules//build and use the real kernel headers from the host, or so Jan 16 22:22:11 adalton, if there is a package for the version you want, you can try adding PREFERRED_VERSION_linux-dummy = "2.6.27" to one of your conf files. Jan 16 22:22:37 (or for the headers package or whatever you want to peg version for) Jan 16 22:31:35 bootlogd.sh is breaking my boot process Jan 16 22:31:49 specially when rc is running S07bootlogd Jan 16 22:31:51 its wired Jan 16 22:32:38 actually, after the bootlogd there is no output from other process but some of the scripts under runlevel 5 are not initialized.. don't know actually Jan 16 22:32:55 I have a recipe which produces several packages. Say, foo, foo-bar, foo-dev, foo-bar-dev, stuff like that. Jan 16 22:33:22 Because of reasons, I want to set SKIP_FILEDEPS to 1 for a single one of those packages. However, this doesn't seem to be easy, at least. Jan 16 22:34:27 Basically, when building foo-bar-dev, ${PN} is still "foo", and it doesn't appear that the foo-bar-dev name is available as a variable that I could add to OVERRIDES, or in any way exposed to me; the only things that seem to use the specific-package name are RDEPENDS_*, FILES_*, and the like. Jan 16 22:34:38 I am mentioning this in case this is a FAQ that I just happen not to have run into before. :) Jan 16 22:45:51 blloyd_: thanks, I'll give that a try Jan 16 22:46:24 Thinking about it, this is probably because the fundamental granularity is wrong -- SKIP_FILEDEPS is being set per-recipe, not per-package, because the filedeps stuff is done per-recipe, not per-package. Jan 16 23:45:49 hey, does anyone know where the screen sleep settings for X and/or Linux console reside? Jan 16 23:46:43 im getting a problem with deb package Jan 16 23:46:45 package architecture (arm) does not match system (armel) Jan 16 23:47:32 i saw some solutions, but it seems to be patches on package_deb.bbclass.. i suppose those patches would be applied already but it doesn't seem Jan 16 23:48:23 blloyd_: what do you mean by screen sleep settings? screen saver? Jan 16 23:50:24 screen saver, yes. Except it's more hardware sleep these days. Jan 16 23:50:34 I need the screen to not sleep. Jan 16 23:51:48 basically, show a system status screen at all times. Jan 16 23:53:47 blloyd_: add in your xorg.conf http://paste.kde.org/649040/ Jan 16 23:53:55 this is disabling the screensaver Jan 16 23:54:36 thanks. I knew it was easy to do. Searches got me 10,000 useless links Jan 16 23:56:27 yes, ive been there Jan 17 00:06:10 guys Jan 17 00:07:44 why commit 1659da8 wasn't applied to oe-core as well? Jan 17 00:07:52 its about the armel deb package problem Jan 17 00:08:24 msm: ping regarding the oprofile issue? Jan 17 00:15:00 Hi, please teach me about relation of the recipe of yocto and OE. Jan 17 00:16:07 yocto uses OE-core. OE has core recipes and non-core. Yocto only uses OE-core and then has it's own recipes above that. Jan 17 00:18:56 sgw1: sadly i did not get a chance to look at it today Jan 17 00:19:03 hopefully tomorrow Jan 17 00:19:39 blloyd_: thanks. for example, although libtiff of OE (danny) is version 4.0.2, libtiff of yocto is using 4.0.3. Jan 17 00:19:49 this recipe is acquired from the master branch of OE. it is written to the commit log. Jan 17 00:20:05 Where is rule written when applying the recipe of OE to yocto? Jan 17 00:21:34 msm: should we take the temporary solution from bogdan and then you can undo that patch? Jan 17 00:21:57 iwamatsu: are you looking at the head of Poky (I think that's what you really are looking at). Jan 17 00:22:15 does yocto has any equivalent apt to rpm? Jan 17 00:22:52 sgw1: that's fine with me Jan 17 00:23:05 ftonello: you mean to translate packages? OE-Core can build .deb, .rpm and .ipk package types Jan 17 00:24:46 sgw1: No, I am checking origin/1.4_M1 branch. Jan 17 00:26:32 iwamatsu: Ok, so danny is the 1.3 release and both poky and oe-core have danny branches that should match Jan 17 00:27:04 iwamatsu: your looking at poky then currently Jan 17 00:27:15 sgw1: no, i mean a upgrade service, like apt is for dpkg Jan 17 00:29:06 because i don't know why oe-core doesn't have a patch to fix deb packages on arm little endian arch Jan 17 00:29:13 ftonello: I think I understand, apt/dpkg and for .rpm there is yum in 1.3 and smart (in 1.4), they both use rpm as the package tool Jan 17 00:29:46 I saw your comment in #oe, where is that commit from? meta-oe? Jan 17 00:30:13 sgw1: yes Jan 17 00:30:37 ftonello: looking Jan 17 00:30:58 sgw1: i cant find this smart on yocto 1.4 Jan 17 00:31:00 neither yum Jan 17 00:31:51 sgw1: that commit fix this error when trying to install a deb package: package architecture (arm) does not match system (armel) Jan 17 00:31:55 ftonello: look in: meta/recipes-devtools/python/python-smartpm_1.4.1.bb Jan 17 00:33:00 ftonello: what repo? I checked for that commit in meta-oe and not there either Jan 17 00:36:54 sgw1: git://git.openembedded.org/openembedded Jan 17 00:37:17 ftonello: interesting I just did a pull from master, which recipe? Jan 17 00:37:31 sorry, oe-classic! Jan 17 00:38:04 sgw1: what repo is meta-oe? and whats the diff? Jan 17 00:38:46 ftonello: oe-classic is the older bits that have been broken apart to oe-core and meta-oe Jan 17 00:39:17 so ppl are not using oe-classic anymore? Jan 17 00:39:27 what is the meta-oe repo url? Jan 17 00:39:47 sgw1: btw, I don't have any meta/recipes-devtools/python/python-smartpm_1.4.1.bb Jan 17 00:40:18 ftonello: correct as far as I know. meta-oe: http://git.openembedded.org/meta-openembedded/ Jan 17 00:40:40 ok Jan 17 00:40:49 ftonello: if you look at oe-core: http://git.openembedded.org/openembedded-core/ it has the latest smart code Jan 17 00:40:51 sgw1: im using poky 8 and there is no smart recipe Jan 17 00:41:20 ftonello: I know that oe-core needs to get apt updated, but there have been some issues with doing it. Jan 17 00:41:45 we have older apt right now, needs someone with expertise! Jan 17 00:42:20 sgw1: hmm, I can not understand. yocto 1.3 uses with danny. Which yocto 1.4 use? if 1.4 uses danny, I think that version of libtiff is same. Jan 17 00:42:36 sgw1: I want to know why you have different versions of the recipe in yocto/1.4 and OE / danny. Jan 17 00:42:49 sgw1: true, that commit got lost on oe-classic.. Jan 17 00:43:08 iwamatsu: you are looking at different versions Jan 17 00:44:59 iwamatsu: yocto/danny and oe/danny share the same recipes OE/master head is in progress for Yocto Project 1.4 (really in the poky repo) Jan 17 00:45:49 * sgw1 will be back shortly Jan 17 00:46:13 sgw1: should i open a bug ticket because of that commit? Jan 17 00:46:45 sgw1: maybe that smart recipe was added after the release of poky 8.0 Jan 17 00:46:53 thats why it doesnt exist in poky Jan 17 00:49:33 sgw1: I see, I understood. thanks. Jan 17 00:59:13 ftonello: yes it was, please open a bug, do you know if that problem was fixed upstream in apt? I know 7.20 is also old Jan 17 00:59:27 iwamatsu: sure thing, glad I could help. Jan 17 01:00:55 sgw1: poky 8.0 uses 0.7.14 Jan 17 01:01:36 and still not working Jan 17 01:01:54 i suppose no one commited anything releated after poky 8.0 Jan 17 01:02:17 i searched for armel in git log and nothing showed up Jan 17 01:05:49 ftonello: right, 8.0 has an even older version. Jan 17 01:12:12 sgw1: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3741 Jan 17 01:12:12 Bug 3741: normal, Undecided, ---, saul.wold, NEW , deb packages problem on arm (gnueabi) architecture Jan 17 01:12:28 nice, didn't know about this bot **** ENDING LOGGING AT Thu Jan 17 03:00:00 2013