**** BEGIN LOGGING AT Fri Nov 01 02:59:59 2013 Nov 01 03:09:45 I put a patch out that received some feedback and I'm a bit confused about v2 patching. It seems gdb creates a patch series, 1 patch for every local commit done. So my current v2 patch series has the first patch all over again followed by the fixup patch, which I don't think is what I should be sending in. What am I supposed to do? Nov 01 03:10:19 seems *git Nov 01 03:42:11 apparently this isn't going to work unless i can disable qa_configure somehow... Nov 01 03:42:20 is there even a way to do that? Nov 01 03:50:15 okay, workaround is adding do_qa_configure to the recipe and changing it to a bb.warn Nov 01 06:07:54 peterwhitfield: erlang_R15B is pushed => https://github.com/sarnold/meta-raspberrypi/tree/master/recipes-devtools/erlang Nov 01 06:14:15 nerdboy: fantastic, I'll try it now Nov 01 06:22:57 and it appears to run on my pi Nov 01 06:23:06 at least the erlang shell does Nov 01 06:28:05 not sure what else to do with it, so you get to test it Nov 01 07:37:55 nerdboy: INSANE_SKIP Nov 01 07:49:11 that didn't work when i tried it last night... Nov 01 07:59:27 nope, still triggers the bb.fatal in the config.log check Nov 01 10:00:12 morning all Nov 01 10:06:07 morning Nov 01 10:11:53 hi JaMa Nov 01 10:22:58 morning folks Nov 01 10:24:00 I have this recipe which I want to build as both native and for the target, however, the one for the target needs to use one of the components from the native package. Nov 01 10:24:27 Do I need to split this into two recipes, APP and APP-native? Nov 01 10:24:39 and let APP depend on APP-native? Nov 01 10:26:08 I though I could use the same recipe, and just use DEPENDS = "APP-native".. Got a dependency loop error... Nov 01 10:28:03 slips: this depends should work Nov 01 10:28:56 bluelightning: any idea about that x11-mobility RFC I've sent yesterday? Nov 01 10:29:17 slips: I think you need something like DEPENDS_append_class-target = " APP-native" Nov 01 10:29:30 JaMa: didn't see that, looking now Nov 01 10:29:43 bluelightning: ah, I'll try that, thanks Nov 01 10:30:13 bluelightning: it's not fixed yet, just please check if it looks familiar to you Nov 01 10:31:36 JaMa: not specifically; my only contact with the qt-mobility recipes was fixing enabling/disabling of some optional dependencies Nov 01 10:31:45 JaMa: there is a bug open for this, let me find it Nov 01 10:32:04 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5414 Nov 01 10:32:05 Bug 5414: normal, Medium, 1.5.1, rongqing.li, NEW , qt-mobility-x11 installs headers and libs in wrong paths Nov 01 10:37:22 bluelightning: ah thanks! Nov 01 11:26:04 what actually does it mean when I add 'x11' to DISTRO_FEATURES or MACHINE_FEATURES ? Nov 01 11:26:08 is the definition of 'x11' in Yocto: "board has graphics card"? Nov 01 11:26:31 and hi all :) Nov 01 11:27:28 Krz-: the defintion of the "x11" DISTRO_FEATURE is "distro supports X11" Nov 01 11:27:32 wha, guest? Nov 01 11:29:26 rburton: so adding x11 enables Xserver and X client libraries and X applications, is that correct? Nov 01 11:29:45 yes Nov 01 11:29:50 fwiw, x11 is a default distro feature Nov 01 11:29:58 so you normally remove it Nov 01 12:12:46 bluelightning: another RFC which could be interesting for you because it's about packagegroups you've designed Nov 01 12:28:32 hi, dylan is failing on arch for me, http://pastebin.kde.org/pyujkxy3w got a clue? Nov 01 12:29:56 bluelightning: rburton ^ Nov 01 12:34:57 lpapp: your tar is too new, see commits recently added to dora which fix that Nov 01 12:36:22 JaMa: after the dora release? Nov 01 12:36:51 i.e. if I fetch 10.0.0, I will still have the same issues? Nov 01 12:36:59 iirc yes, you'll want the dora branch. Nov 01 12:37:11 :( Nov 01 12:37:57 ./meta/recipes-core/base-files/base-files/fstab says "# stock fstab - you probably want to override this with a machine specific one" Nov 01 12:38:02 is there an example how to do that? Nov 01 12:38:21 lpapp: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=d3846f06d1e3faedcbc3c28e22c427bb0088683d Nov 01 12:38:23 say, I have my own distro/machine meta-foo layer. Shall I create a base-files append recipe in there? Nov 01 12:39:01 Net147: I am not after the exact change fixing it later than the dora release, but thanks. Nov 01 13:05:07 lpapp: yes .bbappend with FILESEXTRAPATHS Nov 01 13:28:37 I keep getting an error "APP-dev is listed in PACKAGES multiple times, this leads to packaging errors." Nov 01 13:29:22 my PACKAGES looks like this: PACKAGES_append_class-target =+ "APP APP-dev APP-staticdev" Nov 01 13:29:47 I've tried removing the plus sign without any change. Nov 01 13:30:38 The logfile doesnt provide any other information either. COuld this have anything to do with the fact that I run the recipe twice, (one for native, one for target?) Nov 01 13:35:56 _append + =+ doesn't make much sense Nov 01 13:36:12 use bitbake -e and you'll see that all 3 are already defined in default PACKAGES value Nov 01 13:40:28 JaMa: oh. removed the whole line and it worked... :/ thanks Nov 01 13:49:18 JaMa: why FILESEXTRAPATHS? Nov 01 14:02:22 git branch -a | cutepaste Nov 01 14:02:23 http://pastebin.kde.org/pz6mpetea Nov 01 14:02:31 why don't I see a dora branch in the poky repository? Nov 01 14:03:20 lpapp: strange.. http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=dora Nov 01 14:08:06 I will try to delete the clone, and re-clone. Nov 01 14:09:16 * bluelightning wonders why that would be necessary... Nov 01 14:12:15 bluelightning: wrt packagegroup and allarch, when you have 2 MACHINEs with different TUNE_PKGARCH, then do_package signature of packagegroup recipe is different because of runtime dependencies Nov 01 14:12:20 bluelightning: you are welcome to figure out the issue Nov 01 14:12:29 bluelightning: I'll give you bitbake-diffsigs output in a minute Nov 01 14:13:28 JaMa: I appreciate that, then surely the answer is to exclude those via SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS or similar? Nov 01 14:14:05 it all comes down to whether the signature changing represents a material change in the output... here it seems to me it doesn't Nov 01 14:14:07 bluelightning: nope, because SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS is too coarse grained for that IMHO Nov 01 14:14:33 if we have packagegroup which depends on TUNE_PKGARCH signatures, then why not make it TUNE_PKGARCH as well? Nov 01 14:15:25 "building" packagegroup is fast and it's better to build it once per TUNE_PKGARCH than having one allarch which is overwritten after each switch to different TUNE_PKGARCH Nov 01 14:15:50 I'm not arguing that the latter is desirable, I'm suggesting fixing it in a different way Nov 01 14:16:39 if you use SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS than it wont be rebuilt at all, so e.g. if you change dropbear version, packagegroup will still have old version in RDEPENDS Nov 01 14:17:21 JaMa: I checked that; packagegroup recipes don't end up with the version in the dependencies (I looked at the spec file and the ipk control file) Nov 01 14:17:38 I know it will work in most cases, but listing *all* TUNE_PKGARCH dependencies in layer.conf is worse than building packagegroup e.g. 3 times Nov 01 14:18:15 yeah I'm not advocating adding these in layer.conf - rather that packagegroup.bbclass would take care of that automatically Nov 01 14:19:25 Hash for dependent task dropbear_2013.58.bb.do_packagedata changed from 896fc5280b0cc1fde52eafa3a4224881 to 9c8402e24c1194c380aca19c1d1ec8c7 Nov 01 14:20:03 from bitbake-diffsigs sstate-diff/1383315048/*/*/packagegroup-core-ssh-dropbear/*do_package_write_ipk.* Nov 01 14:22:35 erbo: strange, I see that branch after a fresh clone Nov 01 14:22:47 this is the second time it happens to me with the poky repository.... Nov 01 15:45:04 bluelightning, JaMa: we could list packagegroup as being special in the sstate handling code... Nov 01 15:45:35 RP: right, that should also work Nov 01 18:50:34 Anyone know of any recipes for LAPACK & BLAS? The reference implementations I've found are written in fortran and I'd read that the fortran cross-compiler shouldn't be used. Been doing a lot of googling and trying different things out but haven't had any luck. Nov 01 19:59:25 when you have multiple versions of a package, what determines which version is selected by default? Nov 01 21:15:20 Anyone have any advice on getting the fortran compiler to work? Seems like a few people have tried but I haven't found anyone who has had luck. Nov 01 21:16:24 I'm told it is possible Nov 01 21:16:53 I sort of need to worry about it some Nov 01 21:16:58 fortran that is Nov 01 21:23:49 Is it something /msg Crofton Hey I just noticed your also a VT grad. and it seems like we're both doing OSSIE & embedded work. Nov 01 21:26:35 sayguh: fail! Nov 01 21:27:18 lol yes Nov 01 21:27:34 my face is very red. Nov 01 21:28:02 well you could have said worse Nov 01 21:28:19 serious fail Nov 01 22:01:56 quick question (hopefully) - is it possible to copy the tmp dir into another yocto build rather than have to rebuild everything? Nov 01 22:03:55 just use sstate Nov 01 22:03:59 peterwhitfield: not really, but you can use sstate! Nov 01 22:04:02 timing! Nov 01 22:04:20 sgw_, use shorter answers Nov 01 22:04:33 hehe Nov 01 22:05:16 haven't read much of the detail on state - I''ll go read, but I presume that means point the new build to the state from the old one? Nov 01 22:05:37 damn spell checker - I typed 'sstate' Nov 01 22:06:20 you can point it at the sstate-cache directory either directly (SSTATE_DIR) or via SSTATE_MIRROR Nov 01 22:06:51 k, thanks! will give that a try Nov 01 22:07:14 SSTATE_MIRRORS uses the following style, so be aware: SSTATE_MIRRORS = "file://.* file:////sstate-cache/PATH" Nov 01 22:07:53 SSTATE_DIR is just a //sstate-cache (which can be found in your build dir top level Nov 01 22:08:50 SSTATE_DIR should work for me Nov 01 22:08:59 thanks Nov 02 00:07:02 nerdboy: got the erlang recipes to build properly, but if I include your meta-raspberrypi in my bblayers.conf I get a failure when I run bitbake Nov 02 00:07:10 error is: Nov 02 00:07:15 ERROR: Unable to analyse format of PR variable: 1 | ETA: --:--:-- Nov 02 00:07:16 ERROR: Error executing a python function in : Nov 02 00:07:16 AttributeError: 'NoneType' object has no attribute 'group' Nov 02 00:07:50 lots more lines, but seems to be failing in a recipe unrelated to the rasberrypi meta Nov 02 00:07:58 layer Nov 02 00:08:13 I'm going to try splitting our the erlang stuff into its own layer Nov 02 00:08:21 are you on master branch in the oe repos? Nov 02 00:08:32 hmmm, let me check Nov 02 00:09:31 ah, no Nov 02 00:09:44 otherwise you don't need a separate layer just to build it... just copy the erlang dir to one of the other layers under recipes-devtools/ Nov 02 00:09:53 I've set it up using the gumstix repo setup Nov 02 00:10:03 which is picking specific commits Nov 02 00:10:09 I'll try using master for all Nov 02 00:10:39 I'll try copying it first Nov 02 00:11:08 since I know the current versions work to give me a stable build on the gumstix hardware Nov 02 00:13:26 that's a pretty basic PR setting, so you might need to change it to whatever works in the gumstix world Nov 02 00:22:14 yep, ok Nov 02 00:22:30 seems to build properly now - copied the recipe into an existing layer Nov 02 00:51:47 woohoo! success! Nov 02 00:51:53 thanks nerdboy! Nov 02 00:52:05 owe you a beer :-) Nov 02 00:53:17 * nerdboy likes guinness Nov 02 00:54:01 where ru located? Nov 02 00:54:29 california Nov 02 00:54:36 bay area? Nov 02 00:54:43 next time I'm there :-) Nov 02 00:54:51 south of there... Nov 02 00:55:15 k Nov 02 00:58:47 man, having a bestbuy and a couple of office stores in town seems rather useless if i can't even buy a usb3 cable... Nov 02 00:59:12 well, other than one 3 ft. cable at one store, which is not what i want Nov 02 01:55:25 hi all, anyone know how to setup connman for a static IP ... just by adding a script to the build.?? Nov 02 02:01:33 yocti: any clue? Nov 02 02:01:33 brm: Error: 'clue?' is not a valid nick. Nov 02 02:02:42 silviof1: know anything about connman? **** ENDING LOGGING AT Sat Nov 02 02:59:57 2013