**** BEGIN LOGGING AT Wed Nov 09 02:59:57 2011 Nov 09 04:19:51 <_JOEL_> question here, is there a BSP somewhere for the sheevaplug or some other BSP out there to base recipies on that support arm5tel Nov 09 08:25:15 good morning Nov 09 13:35:06 hi. my first build of image but runqemu says "init mouse failed" and "SDL(unable to open mouse)". Can you help please? I'm running it in Xen/domU using SDL vfb. VNC vfb works without problem. Nov 09 13:38:12 ok. solved. it was permission issue :-( Nov 09 15:23:53 zenlinux: The dash problem isn't quite that bad, a lot of our scripts use /bin/bash so those are fine Nov 09 15:24:01 zenlinux: Its just generic code we need to be careful with Nov 09 15:24:10 (which runs under /bin/sh) Nov 09 15:58:38 hi dvhart Nov 09 15:59:05 morning sir Nov 09 16:00:17 dvhart: btw, which versions of the beagleboard do we consider "tested"? (I'm updating README.hardware) Nov 09 16:00:28 at the moment it only lists C4 and xM rev A Nov 09 16:04:20 That's correct Nov 09 16:04:47 the xM rev C has some issues and we haven't been able to get enough testing or hardware to fix it. Nov 09 16:05:00 We should probably see about getting some more hardware. Nov 09 16:07:14 ok, for now I'll add B to the list Nov 09 16:14:09 thanks Nov 09 17:30:08 hi. I have two similar x86 machines with different VGA. what's the best practice to build image for them? using different image target or different layer or different machine? Thx Nov 09 19:27:56 no best practice? Nov 09 19:43:13 jkprg, what do you mean by different vga? they have different vga graphics cards? Nov 09 19:43:42 it what way do you want the resulting images to differ? Nov 09 19:43:48 dvhart, yes. different vga graphic cards Nov 09 19:44:23 basically both images should be same but vga driver Nov 09 19:45:13 both are touchscreen terminals. but they are different revisions. Nov 09 19:45:24 typically you will would prepare a layer with a machine config which defines the necessary xorg bits Nov 09 19:45:33 we usually do one machine per layer Nov 09 19:45:42 but you can also do two in the same layer Nov 09 19:46:01 if the arch is the same, it will save you time to at least share sstate Nov 09 19:46:28 I would probably build each from the same build dir if they are that similar, just changing the MACHINE= line Nov 09 19:46:42 see the various meta-intel/meta-$MACHINE layers for examples Nov 09 19:47:54 I was studying meta and meta-yocto and found multiple machines there. YP is so flexible it's a bit difficult best scenario for beginners :-) Nov 09 19:48:17 *to find best scenario Nov 09 19:48:27 anyway thx Nov 09 19:49:09 ad flexibility - distro, machine, target, layer … Nov 09 19:49:31 did I answer your question? you have a path to get going? Nov 09 19:49:37 yes. thx Nov 09 19:49:44 OK - good luck! Nov 09 19:52:45 thx. I'd like to generate not an image but NFS root inside filesystem directory I would export into NFS immediately. I've started to read all those scripts to find if there is any out-of-the-box parameter. Nov 09 19:53:26 So far I haven't found anything like that. Is it correct? Nov 09 20:11:00 No parameter that I'm aware of. Nov 09 20:13:15 something similar is done by the ADT but I don't know specifics Nov 09 21:58:13 how do I get glib-2.0 on my nativesdk if it's being renamed to libglib-2.0? Nov 09 22:04:33 easiest way seems to be to include something else that depends on glib-2.0 Nov 09 22:09:38 ugh it renames all rpms with libraries it seems? Nov 09 22:11:19 renaming occurs if you have the debian style naming enabled Nov 09 22:11:32 (I assume it names both target and host packages using the same renaming rules) Nov 09 22:12:14 it's "INHERIT_DISTRO" that does this.. I change to to "devshell sstate license" Nov 09 22:12:32 distro/defaultsetup.conf:INHERIT_DISTRO ?= "debian devshell sstate license" Nov 09 22:12:35 thats the default Nov 09 22:14:14 is renaming important? Nov 09 22:14:18 we dont we just disable it? Nov 09 22:14:31 esp. if I need to pick packages for installation in the SDK Nov 09 22:14:53 I don't understand how the SDK relates to this.. Nov 09 22:15:00 a package is a package, doesn't matter what the name is.. Nov 09 22:15:10 the rename script simply renames the package based on debian rules.. Nov 09 22:15:25 well in my SDK, if I want to include some target libraries for use with the toolchain Nov 09 22:15:29 if you don't want them you can simply disable it.. but it is a distro wide decision -- so you need to make sure you set it at the beginning of the build, not the end Nov 09 22:15:55 the packages are still being generated.. but instead if libz1 (debian name) it would be zlib Nov 09 22:16:01 I can do TOOLCHIAN_TARGET_TASK += glib-2.0 Nov 09 22:16:09 it builds fine, but it can't find the RPM on rootfs creation Nov 09 22:16:22 they are built fine it seems Nov 09 22:16:27 its just the final package bit Nov 09 22:16:29 you are mixing and matching source and target package names Nov 09 22:17:05 the debian rename will rename dependencies as well.. so if you require zlib (target package) it will rename that automatically as well.. Nov 09 22:17:06 im just adding a package to be installed in the SDK AFAIK Nov 09 22:17:23 the problem you are having is different.. you need a way to translate a source package name to a specific target sub-package Nov 09 22:17:34 right Nov 09 22:17:47 short of querying each package, I'm not sure if there is an automatic way of doing this.. Nov 09 22:18:28 If you use RPM as the packaging back end, you can specify dependencies on a filename basis.. but that is RPM specific.. (deb and ipkg really don't like that) Nov 09 22:18:57 hmmmm Nov 09 22:19:25 ...and if it doesn't work with the RPM backend, let me know and I'll see what I can do to fix it.. Nov 09 22:19:27 it's supposed to work Nov 09 22:19:52 I've hacked at this before Nov 09 22:20:04 I need an anther VAR for install rpm list Nov 09 22:20:10 that does not effect bitbake dependecies Nov 09 22:20:18 thats the simple fix at least Nov 09 22:21:39 bitbake dependencies can not be specified in the form of filenames.. only DEPENDS -- build package names and RDEPENDS -- target package names Nov 09 22:21:53 this is where a lot of folks get confused and put the wrong things in the wrong places.. Nov 09 22:22:34 well Nov 09 22:22:37 im confused Nov 09 22:22:42 I'm not sure the best approach for this, other then I've always had to (in the past) simply look fo the target package name and pick it.. Nov 09 22:22:47 i've essentially done RDEPENDS += glib-2.0 Nov 09 22:22:58 if it's specified in the recipe itself it's fairly easy to find.. but if it's not you just have to know it.. Nov 09 22:23:11 via? Nov 09 22:23:21 what does glib-2.0 recipe say I need to add to RDEPENDS? Nov 09 22:23:37 what do you mean? Nov 09 22:24:22 I have a library glib-2.0 Nov 09 22:24:29 i want it to be built during the build still Nov 09 22:24:41 and i want /usr/lib/libglib* to be installed in the target Nov 09 22:25:04 looking at my current build.. the glib-2.0 (source) package produces binary "default" binary packages + a "codegen" package.. Nov 09 22:25:39 so when I RDEPENDS += "glib-2.0" Nov 09 22:25:48 or zlib for instance Nov 09 22:26:00 | Processing task-core-standalone-sdk-target... Nov 09 22:26:00 | Processing dtc... Nov 09 22:26:00 | Processing libxml2... Nov 09 22:26:00 | Processing ncurses... Nov 09 22:26:00 | Processing zlib... Nov 09 22:26:01 | Unable to find package zlib (zlib)! Nov 09 22:26:02 the default packages include the library.. and put it into "glib-2.0".. along comes debian.bbclass and renames it to libglib-2.0 Nov 09 22:26:14 zlib is easier to explain Nov 09 22:26:31 what you specified is not an RDEPEND, but litterally "install this package" no translations occur on it Nov 09 22:26:31 yes Nov 09 22:26:50 debian.bbclass will transform the RDEPENDS.. but does nothing anywhere else.. Nov 09 22:26:57 point is Nov 09 22:27:02 i can do RDEPENDS += libz Nov 09 22:27:06 CANT Nov 09 22:27:14 the problem you are having is that you want the transform to occur universally Nov 09 22:27:37 because then I get Missing or unbuildable dependency chain was: ['libz'] Nov 09 22:27:39 The RDEPENDS would be to "zlib".. the non-transformed name Nov 09 22:27:44 yes Nov 09 22:27:51 sounds like I need to disable debian.bbclass Nov 09 22:27:52 internally in recipes, they have no concept of the transformed names Nov 09 22:28:11 if you add to your image, task, etc.. RDEPENDS += zlib -- you would get the right thing.. Nov 09 22:28:33 if you use one of the variables that simply feeds the backend opkg/deb/rpm rootfs classes -- no transforms occur so you need to know the final package name.. Nov 09 22:28:38 this is certainly inconsistent.. Nov 09 22:29:01 so I need to make a task for this? Nov 09 22:29:15 (I hate the automatic transforms myself.. but it's internally consistent within the recipes and dependency system) Nov 09 22:29:31 ya.. this took me a long time to come to grips on.. Nov 09 22:29:54 the task just adds one more level of indirection which makes the whole thing sort of work? Nov 09 22:29:56 If you don't like one of the default taks or image types.. the right approach isn't to add something to the install variables.. but it's to create your own image rule.. Nov 09 22:30:10 you can even do core-image-minimal.bbappend and add it via that approach if you wanted.. Nov 09 22:30:29 RDEPENDS += zlib you've now modified it that you want want the zlib package, even if nothinge lse uses it Nov 09 22:31:10 ... so to come back to the beginning... Nov 09 22:31:22 I'd recommend you disable the debian.bbclass... get whatever you are doing work.. Nov 09 22:31:32 then re-enable it.. whatever fails -- file a defect on it.. Nov 09 22:31:44 well i already have my own image rule loosly based off another one Nov 09 22:31:50 cause whatever failed to build/install -- is not being transformed by the debian.bbclass, as it should be.. Nov 09 22:32:10 inside of the recipes you never refer to debian style names -- only refer to the actual recipe contents and naming.. Nov 09 22:32:22 so turning off debian.bbclass ensures that you aren't getting trapped by that Nov 09 22:32:55 (end result.. what works with debian.bbclass disabled is supposed to work with it enabled.. I doubt many people have disabled it and enabled it to check that it's working at this point) most of the oe folks seem to like the debian sytle naming.. Nov 09 22:33:16 I've certainly played with it disabled before, but that was just to get rid of the transofrms so I could understand what was happing a bit quikcer Nov 09 22:36:24 fray: making a task seems to have worked Nov 09 22:37:35 it would be possible for a task to be transformed (it's not, but it's possible).. Nov 09 22:37:59 well I can specify a single name for something, have it build… then install the right transformed package Nov 09 22:38:01 so in the end the real issue is that we need to make sure all of the ways to control installs are transformed as well Nov 09 22:38:03 so that's what I want Nov 09 22:38:13 yes Nov 09 22:38:16 i think that's it Nov 09 22:38:27 call the transform function on the INSTALL_PACKAGE_RPM Nov 09 22:38:31 in populate_sdk Nov 09 22:38:37 or something close to that Nov 09 22:40:14 Ya.. that is my guess.. but I'm still at a bit of loss to understand exactly all of the pieces people use to inject target packages into the build.. (i.e. everything that is supported or exists -- that should be transfomed) Nov 09 22:40:59 It seems to me there are too many ways current to control what ends on on the rootfs.. Nov 09 22:45:13 indeed Nov 09 22:45:33 I dunno, I think it adds a certain feeling of adventure and mystery to the process. Nov 09 22:46:36 I should totally add a "sometimes return random stuff" option to pseudo for people who think software development isn't as fun as it was in the 80s. Nov 09 22:47:25 msm can you add a bug on this.. give me the number and I can add some comments, if necessary.. Nov 09 22:47:33 this is something we should try to fix Nov 09 22:57:25 ugh Nov 09 22:57:26 i was wrong too Nov 09 22:57:29 this just is not working Nov 09 22:57:32 grr **** ENDING LOGGING AT Thu Nov 10 02:59:58 2011