**** BEGIN LOGGING AT Thu Nov 21 02:59:59 2013 Nov 21 08:04:47 good morning Nov 21 08:51:50 hi Nov 21 08:52:36 is there a ready to use configuration for a Marvell px1666 chip (xscale, armv5te) in yocto? Nov 21 08:52:59 sorry the correct name is pxa166 Nov 21 08:53:31 mrAlmond: in Yocto not by sure, you will need a meta layer Nov 21 09:12:16 hi yoctoiden... Nov 21 09:12:20 What is the dora-toaster branch? Nov 21 09:13:08 Exists somewhere a description of all branches of the poky-repository? Nov 21 09:53:01 looks like toaster already merged to master Nov 21 09:57:47 morning all Nov 21 10:02:01 HI all, how to get information about the recipe for a certain package - which one is used, where is it located, etc... Nov 21 10:06:15 drasko: i don't think there is a 'nice' or proper way to do that... what i do, is dpkg -I xxx.ipk, and it gives you at least the 'recipe' name in the OE field. Nov 21 10:06:56 the info is in pkgdata on the host as well (TMPDIR/pkgdata or TMPDIR/sysroots//pkgdata in newer versions) Nov 21 10:07:02 ndec, bitbake -vf can help... Nov 21 10:07:14 but I hoped that there was some instruction to bitbake Nov 21 10:07:18 to give an info... Nov 21 10:07:51 I've recently made some extensions to oe-pkgdata-util in master that will allow looking up the recipe a package comes from, looking up the package name after renaming (eglibc -> libc6), etc. Nov 21 10:09:04 drasko: i thought you wanted to get from package. Nov 21 10:09:37 ndec, no, only iformation which one is used Nov 21 10:09:50 where to find it Nov 21 10:10:02 where to find the recipe .bb file? Nov 21 10:10:07 yes Nov 21 10:10:48 I have a large tree with IMAGE_INSTALL var set and packages scattered all over Nov 21 10:10:51 toaster is also designed to help with these kinds of questions Nov 21 10:11:04 (although it's not really ready to use atm) Nov 21 10:12:05 I was sondering if I have wpa_supplicant_1.bb in meta/yocto Nov 21 10:12:24 and I put wpa_supplicant_2.bb in my meta-drasko Nov 21 10:12:30 which one will be built? Nov 21 10:12:54 bitbake-layers show-recipes i guess will help. Nov 21 10:13:16 it doesn't give the path, but at least the layer. Nov 21 10:13:47 ndec, nice Nov 21 10:25:07 bitbake-layers can give the path for show-recipes (or show-overlayed) with -f Nov 21 10:33:37 bluelightning, exactly what I was looking for! Thanks. Nov 21 10:39:15 mckoan : hi, I was asking about armv5te build...now I've verified that this chip uses march armv4...otherwise binaries will not work Nov 21 10:39:32 so is there an example on how to build an image with armv4 arch? Nov 21 10:42:58 mrAlmond: you can find somenthin in OE looking for Gumstix S3C2410 Nov 21 10:43:48 mckoan : great tnx! Nov 21 10:44:03 or maybe Openmoko GTA01 bv3, bv4 (s3c2410) Nov 21 10:45:49 thank you again Nov 21 10:52:51 bluelightning, why I can not name my recipe like thisL Nov 21 10:52:54 wpa_supplicant_2.0.bb Nov 21 10:53:10 bitbake -vf wpa_supplicant Nov 21 10:53:18 never finds a packege named like this Nov 21 10:56:21 drasko: underscores can only be used to separate the name and version Nov 21 10:56:32 drasko: use wpa-supplicant instead Nov 21 10:56:49 bluelightning, OK, I did not know that it was mandatory Nov 21 11:01:32 bluelightning, if I have wpa-supplicant_1.0.bb in one meta layer, and wpa-supplicant_2.0.bb in other meta layer, how to force compilation of recent one (i.e. 2.0)? Nov 21 11:02:38 drasko: unless there are preferences in place already. the newer version is preferred Nov 21 11:02:46 drasko: if the two recipes are in different layers, the relative layer priorities will influence which one gets picked (highest priority wins) Nov 21 11:02:55 drasko: if the priority is equal, higher version wins Nov 21 11:03:11 drasko: if you want to just force it, do PREFERRED_VERSION_wpa-supplicant = "2.0" in local.conf or your custom distro config Nov 21 11:03:15 bluelightning, OK, so I have 1.0 in "meta" Nov 21 11:03:21 which will always win Nov 21 11:03:39 let me add then PREFERRED_VERSION_wpa-supplicant = "2.0" Nov 21 11:03:59 drasko: it will win only if your other layer has a lower priority set in its layer.conf Nov 21 11:04:34 bluelightning, I thought that "meta" meta layer is always the biggest priority Nov 21 11:04:43 how to check? Nov 21 11:04:57 drasko: nope, it has priority 5 Nov 21 11:05:01 drasko: bitbake-layers show-layers Nov 21 11:05:35 bluelightning, and how to change layer priorities? Nov 21 11:06:06 you can change a layer's priority by setting LAYER_PRIORITY in conf/layer.conf under the layer Nov 21 11:06:21 er Nov 21 11:06:28 actually BBFILE_PRIORITY, sorry Nov 21 11:07:12 drasko: if you haven't already I'd suggest reading http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers Nov 21 11:10:38 found it there, thanks a lot Nov 21 11:11:05 i find it a little weird that layer priority is 'set' by the layer, and not in bblayers.conf (e.g. by the person who uses the layer). Nov 21 11:11:45 since layers are designed to be used together 'randomly', it's weird to let layers set their own priorities. Nov 21 11:27:00 Hi all, trying to build with the meta-fsl-arm layer and can build an image but would like to build the packages as package_deb instead of package_rpm however I got an error saying that it can't get the apt_0.9.9.4 source. What's the best way of going about updating the apt recipe to include a older/later version? Nov 21 11:30:12 beaver_545: the problem is that the debian servers are almost entirely down right now Nov 21 11:30:22 it should have hit our mirrors though... Nov 21 11:32:50 I can access the source for apt from ftp://ftp.debian.org/debian/pool/main/a/apt it's just that there's only apt_0.9.7.9.tar.gz or apt_0.9.12.1.tar.gz Nov 21 11:33:07 oh yeah, apt is interesting Nov 21 11:33:14 you can grab it from snapshot.debian.org instead Nov 21 11:33:22 and put it in your downloads directory Nov 21 11:34:14 I've tried to point the SRC_URI to 0.9.7.9 but then I'm getting another error... was wondering if i'm doing it properly or not! Nov 21 11:34:30 just grab the right tarball and you'll be fine Nov 21 11:34:45 ahhh thanks i'll give it a try :) Nov 21 14:07:07 Hi guys, I was build using yocto my first build yeasturday but it failed over night due to lack of disk space, I've moved everything to a new disk and reset the links in bblayer, but now when I build it errors with a lot of BEGIN failed--compilation aborted ... and ERROR: Task 3862 (virtual:native:/home/dave/yocto/fsl-community-bsp/sources/poky/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.26.5.bb, do_configure) failed with exit code '1 Nov 21 14:07:07 i'm using the wrong terms ? Nov 21 14:27:53 D4v33: delete your tmp/ and let it rebuild it Nov 21 14:49:53 rburton: I did that now I get "ERROR: Only one copy of bitbake should be run against a build directory Nov 21 14:49:53 "? Nov 21 14:50:28 D4v33: there must be bitbake processes hanging around, use ps and kill them Nov 21 14:50:32 pkill -f bitbake Nov 21 14:50:35 :) Nov 21 14:52:20 That's it, thanks guys :) Nov 21 15:04:38 interestingly MACHINE only seems to be picked from the environment and not from the local.conf file? Nov 21 15:06:05 that's incorrect Nov 21 15:06:35 note that if you're using ?= in the local.conf, it would prefer the env value if set, as ?= means "set only if unset" Nov 21 15:10:01 kergoth: sorry I don't understand your sentence fully, when I first did the install it was set to ??=, I've since changed that to ?= Nov 21 15:10:47 kergoth: I get your sentence now... call me slow! Nov 21 15:18:56 Ok, this is not working. The example given in the poky manual 'Board Support (BSP) Developers Guide' in section 'Customizing a Recipe for a BSP' (see:http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#customizing-a-recipe-for-a-bsp). Nov 21 15:19:32 The example is to change the recipe for the init-ifupdown. Nov 21 15:20:17 If I follow the example exactly as given, it still builds out the rootfs containing the interfaces file from the main meta/recipes-core/init-ifupdown Nov 21 15:24:28 The changes appear in the tmp/work/-poky-linux-gnueabi/init-ifupdown/1.0-rX/ directory, but it does not propagate into the rootfs image. Nov 21 15:25:45 This has always been an issue for oe, task vs image. Do you have to do a 'bitbake clean core-image-minimal' then 'bitbake core-image-minimal' to propagate appends to recipes? Nov 21 15:26:29 nope. images are always built from scratch Nov 21 15:29:38 Odd though, the build runs and reports 'Attempted 1467 tasks of which 1454 ...', changes show up in the tmp tree, but not in 'tmp/work/ilnx-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs' Nov 21 15:29:46 shouldn't the rootfs image have changed? Nov 21 15:30:51 The ext3 image has not changed either. Nov 21 15:33:24 kergoth: what does work is 'bitbake -c clean core-image-minimal' ; bitbake core-image-minimal' Nov 21 15:35:02 T0mW: so just to understand the sequence, you built core-image-minimal, then added a bbappend for init-ifupdown, and then did bitbake core-image-minimal again? Nov 21 15:35:05 There seems to be a disconnect between the dependancy of a .bbappend vs the image. Nov 21 15:35:07 and nothing else? Nov 21 15:35:19 correct Nov 21 15:36:03 tmp shows the new revision with the change in the appropriate file, but the change never gets moved into the rootfs image. Nov 21 15:37:13 only by cleaning the image out (bitbake -c clean ) then rebuilding the target (bitbake ) does the target rootfs change (e.g. core-image-minimal). Nov 21 15:38:57 It's like the PRINC is ignored in preference to the PR of main meta/ recipe when the image builder runs? Nov 21 15:39:42 I can deal with it, it just is that the docs are incorrect. Nov 21 15:41:04 Well, technically, the doc is not incorrect, the effect does occur where the recipe is modified, but the change is not propagated until you force a rebuild of the image. Nov 21 15:43:27 what version of yocto is this? Nov 21 16:24:16 kergoth: 10.0.0 Nov 21 16:26:53 kergoth: I'm just wondering if I'm setting things up wrong. Normally, I would have just gone into the meta tree and changed the recipe there, but with migrating from 5.0.1 to 10.0.0, I'm faced with tracking down those changes to move them into Dora. So, with Dora, I'm following the documentation. Nov 21 16:27:02 T0mW: if it is behaving as you describe it's a bug, not a documentation issue Nov 21 16:27:20 bluelightning: anomoly Nov 21 17:20:02 Hi all, Does mt9v032 camera driver works only with kernel 2.6? As I see there's a recipe /yocto/poky/meta-ti/recipes-kernel/linux/linux-omap_2.6.39.bb and mt9v032 patch in ~//linux-omap-2.6.39/camera/0002-v4l-Add-mt9v032-sensor-driver.patch Nov 21 17:20:14 Anyone has any experience with this? Nov 21 17:20:38 I am struck past many days getting this camera driver working. Nov 21 17:22:40 I am using kernel 3.5.0 Nov 21 17:28:59 moin Nov 21 19:45:20 drat, "QA Issue: non debug package contains .debug directory" Nov 21 20:21:40 walters: i presume glib's installed test suite works for you in gnome-os out of the box Nov 21 20:22:09 rburton: s/gnome-os/gnome-continuous/ and yes, but note that Continuous runs installed tests in a virtual machine Nov 21 20:22:26 in fact it runs the tests in a basically identical environment to that users actually run Nov 21 20:22:38 in a logged in desktop Nov 21 20:22:41 ok Nov 21 20:22:52 i should replicate the fails and see what actually fails, start debugging etc Nov 21 20:22:55 cheers Nov 21 20:23:26 are you using a VM? container (systemd-nspawn)? overgrown chroot (mock/pbuilder) ? Nov 21 20:50:47 Is there a way to list all the dependencies of a package I might want to build using bitbake without generating and viewing the .dot graph? Nov 21 20:54:02 well, you could always use bitbake -e to examine the DEPENDS and RDEPENDS_* variables Nov 21 20:54:09 beyond that, not really Nov 21 20:55:03 the 'bb' tool has a whatdepends command that does the reverse, lists what depends on something, but currently it doesn't handle runtime at all, only build time, which really limits the usefulness Nov 21 20:55:15 hopefully the bitbakek shell work going into yocto 1.6 will improve matters Nov 21 20:56:45 Would there be any advantage to building the world (bitbake world) while assembling a distro for the first time? I mean, would it cut down on compile / build times as stuff would be in the sstate-cache? Nov 21 20:57:39 a real world build can take days, depending on the layers included Nov 21 20:57:51 hmmm Nov 21 20:57:56 it builds every recipe, including those you might never build Nov 21 20:58:10 so i'd question the value of that. it would prepopulate the cache, but if you never build those things, you woulnd't use those sstates :) Nov 21 20:58:26 ok, then it is a stress test then. Nov 21 20:58:32 nm Nov 21 20:58:37 also, sstate can still be somewhat brittle, for example, a change to DISTRO_FEATURES will invalidate nearly the entire cache Nov 21 20:58:47 but yeah, youc ould certainly do it as a test or experiment or just for the hell of it :) Nov 21 20:59:02 * kergoth 's done builds like that just to keep his build machien busy and see what explodes Nov 21 20:59:04 oh, that is what I was intending on doing (DISTRO_FEATURES_append) Nov 21 20:59:13 yeah, right. Nov 21 20:59:18 LOL Nov 21 20:59:33 the thing is, distro features is a list, and generally when a recipe uses it, it only cares about a small subset of that Nov 21 20:59:41 but the caching mechanism sees it just as a string Nov 21 20:59:53 it doesn't know those recipes only care about whether N elmeents exist in teh list Nov 21 20:59:59 like, "touch this wire, it won't do anything" as my cousin told my brother about the cattle fence Nov 21 21:00:06 so even adding a space to distro features will result in rebuilding every reicpe that touches distro features Nov 21 21:01:02 yeah, found that out, about the total rebuild. Nov 21 21:01:04 kergoth: Thanks. Nov 21 21:01:09 np Nov 21 21:01:36 * T0mW does one more build before pulling the plug Nov 21 21:01:52 and of course, reubilding recipe A when B depends on A will also result in rebuildilng B. so changes ripple outward through the dependency digraph Nov 21 21:01:53 I guess I can spew out a .dot and manually examine it? Will that work? Nov 21 21:02:05 mtahmed: yeah, trying to create an image with graphviz isn't worth it, it's too big to process Nov 21 21:02:12 either read it manually with a text editor, or try using depexp Nov 21 21:02:17 bitbake -g -u depexp core-image-base Nov 21 21:02:24 will pop up an x11 UI to examine the deps Nov 21 21:02:35 unfortunately it doesn't show Nov 21 21:02:52 erm, doesn't show why the dep is there, whre it came from, and wha tit shows for runtime vs build time is limited Nov 21 21:02:56 but it's definitely useful from timet o time Nov 21 21:03:03 Okay I will try to do a mix of manual viewing and regex. Nov 21 21:03:28 I basically am at a stage where I am building everything except a few packages using the gnu toolchain. Nov 21 21:03:34 yeah, i usually end up just grepping the .dot half the time Nov 21 21:03:47 And want to systematically go through the dependencies and enable them to compile with llvm Nov 21 21:04:21 So maybe I will start with the graph leaves and go inward? Nov 21 21:42:01 * kergoth kicks anonscm.debian.org Nov 22 01:41:54 So I added jffs2 to IMAGE_FSTYPES in my machine conf, but when I run bitbake it doesn't output a jffs2 image. How do I get it to pick up the change without building from scratch? Nov 22 02:33:30 tastycactus: how (exactly) did you add jffs2 to IMAGE_FSTYPES? Nov 22 02:33:42 i've been banging my head against the wall all day on something very similar Nov 22 02:53:00 mtahmed: while it would be good to be more systematic, what's wrong with doing core-image-minimal and fix what's broken? **** ENDING LOGGING AT Fri Nov 22 03:00:00 2013