**** BEGIN LOGGING AT Tue Oct 14 02:59:59 2014 Oct 14 08:36:54 morning all Oct 14 08:44:13 hi bluelightning Oct 14 08:44:21 hi woglinde Oct 14 09:02:39 morning all! quick question - if I do BBCLASSEXTEND = "native", and I have RDEPENDS_${PN} = xxx in my recipe, bitbake doesn't seem to build and install the -native versions of the runtime dependencies. (using yocto 1.5) Is that supposed to happen automatically? Oct 14 09:03:53 (when building the -native version of the package) Oct 14 09:05:50 Or do I still need to add explicit -native versions of the depending packages into the RDEPENDS? Oct 14 09:07:12 it seems that looking at native.bbclass this shouldn't be necessary due to native_virtclass_handler(), but for some reason that doesn't work (for me) Oct 14 09:11:10 andre_d RDEPENDS is for RUNTIME-Depends Oct 14 09:11:30 and you need it only when no shared libs are involved Oct 14 09:11:41 DEPENDS is for runtime Oct 14 09:11:41 yes Oct 14 09:11:48 ups buildtime Oct 14 09:11:49 sorry Oct 14 09:12:41 I need some -native stuff during runtime of my -native tool, not during build time. So I them in RDEPENDS Oct 14 09:12:48 have Oct 14 09:12:55 ? Oct 14 09:13:00 runtime is runtime Oct 14 09:13:03 and not host Oct 14 09:13:18 but the -native in DEPENDS line Oct 14 09:15:36 sometimes its working automagicly when one recipes which has BBCLASSEXTEND = "native" and depends on another -native package Oct 14 09:15:56 I have a host tool (tool-native) that runtime depends on other host stuff (stuff-native). I have a recipe for 'tool' and 'stuff' where both BBCLASSEXTEND = 'native' and 'tool' rdepends on 'stuff'. This is working fine when building for the target: 'stuff' gets installed together with 'tool' into the target filesystem. But a bitbake build of tool-native doesn't cause stuff-native to be installed into the host sysroot Oct 14 09:17:13 or even built Oct 14 09:18:34 yes, it does work if I make tool DEPENDS on stuff, but it's not a build time dep, it's a runtime dep Oct 14 09:20:38 it also works if I explicitly make tool-native RDEPENDS on stuff-native, but then the recipe is not generic anymore, as the target version of tool will have to depend on stuff, not stuff-native Oct 14 09:21:35 wait what? Oct 14 09:22:23 from -native recipes no packages are build Oct 14 09:22:34 so they will not show up in any image Oct 14 09:23:13 if you really need some "native" stuff in the image you have to compile in the target recipe and package it Oct 14 09:24:36 I don't want -native things in the target image, i want -native things in the host sysroot :-): tool runtime depends on stuff, so I have RDEPENDS_${PN} = "stuff" in the tool recipe. this is working fine, both end up in the target image. Oct 14 09:24:53 I _also_ want a -native version of 'tool' Oct 14 09:24:58 in my host sysroot Oct 14 09:25:13 so I add BBCLASSEXTEND = 'native' to both recipes Oct 14 09:26:06 now a bitbake tool-native builds and installs native version of tool into my host sysroot. but it doesn't cause stuff-native to be installed into the host sysroot Oct 14 09:27:03 as I said than add DEPENDS = "foo-native" Oct 14 09:27:56 but the target version doesn't depend on the -native version. I can make two recipes, but I wanted to avoid duplication Oct 14 09:27:59 woglinde: thanks for forwarding the GA room change Oct 14 09:28:08 crofton ;) Oct 14 09:29:42 isn't native_virtclass_handler() in native.bbclass supposed to take care of that? I guess it's not working right? Oct 14 09:29:46 andre_d okay so the problem is you have package one which has native and target tools and you have package two which depends only on the native package of tool one? Oct 14 09:32:59 no. I want to build package1 both for the target and for the host. package1, to be able to _run_, needs package2. I need to run package1 on the host, and I need to have package1 in my target image. In any case, package1 runtime depends on package2 and package1-native runtime depends on package2-native (only) Oct 14 09:34:33 so i will have four packages, package1 (rdep package2) for the target, and package1-native (rdep package2-native) for the host Oct 14 09:34:50 no rdep Oct 14 09:34:52 depends Oct 14 09:34:55 no build time depends Oct 14 09:35:01 ???? Oct 14 09:35:04 yes Oct 14 09:35:45 all -native depends are build time depends Oct 14 09:35:57 in native you can not have rdepends again Oct 14 09:36:06 ok :-( Oct 14 09:36:27 ah, but Oct 14 09:36:35 DEPENDS is you friend Oct 14 09:36:39 again Oct 14 09:36:51 uhm Oct 14 09:36:57 DEPENDS_nativre Oct 14 09:36:59 sorry Oct 14 09:37:02 mom Oct 14 09:37:29 if I create a recipe package-native.bb and explicitly add RDEPENDS_${PN} = 'package2-native', it works Oct 14 09:37:57 DEPENDS_class-native Oct 14 09:38:02 now i have duplication, but bitbake installs package2-native into the host sysroot. Oct 14 09:38:03 is what you need Oct 14 09:38:19 sorry its some times I needed it Oct 14 09:39:39 ok, I'll do that instead. Thank you! Oct 14 10:08:14 shouldn't json-c PROVIDE = "libjson" ? Oct 14 10:23:08 Crofton: the GA room has changed? I don't see that email Oct 14 10:47:51 ndec: yes, I got an email about that, I have deleted it though :-( Oct 14 11:03:38 FYI.. OE e.v. is starting in a minute or so.. room 111 Oct 14 11:03:52 If anyone is on their way let me know.. ;) Oct 14 11:56:57 bluelightning, about your test setup using LAVA and some script glue: how do you get test software onto the target? Oct 14 11:57:54 i guess i have a few options: put SDK on target and compile them on demand, provide a package manager and install packages on demand, or create a special image recipe that includes all the packages needed Oct 14 12:28:32 mago_: the deployment stuff that's already in OE-Core takes care of that Oct 14 12:28:49 how? Oct 14 12:28:51 mago_: mostly though the approach is to test only what's installed rather than installing stuff to test Oct 14 12:29:38 lets say you want to run network performance test. normally, we don't ship iperf on target, but we need it during test Oct 14 12:31:32 bluelightning, what kind of deployment stuff in oe-core are you referring to? opkg? Oct 14 12:31:57 there's no in-built support for installing packages, although we do do package installation as part of testing the package system itself Oct 14 12:32:12 so the current approach would be to just supply an image with the required packages in it already Oct 14 12:32:23 alright Oct 14 13:18:18 bluelightning, so you recommend making a one-to-test-it-all type image? i mean, you typically want to test all sorts of things in the system, everything from hardware interfaces/subsystems (usb, net, storage, pm, pcie etc) to more high level stuff such as testing your JVM, etc.This image would become quite big pretty fast Oct 14 13:19:39 mago_: it could yes Oct 14 13:20:21 mago_: all I can say is, this is how our minimal test framework works now; it could be extended to do install..test..uninstall if people need that Oct 14 15:40:55 Dear all, when running 'bitbake -c testimage ', '-v' debug switch does not help with producing 'more verbose' output from the test runner. Is there a way to output all stdout to console UI? Oct 14 20:02:38 Hi guys. Oct 14 20:02:56 Trying to write a new recipe and running into an issue with the SRC_URI checksums. Oct 14 20:03:17 I am pulling from git and have SCRREV set, but it seems I get a different checksum calculated each time... Oct 14 20:06:20 what makes you think you get a different checksum calculated each time? Oct 14 20:06:45 When I execute do fetch it fails every time, and it gives a new checksum Oct 14 20:06:59 gives where? Oct 14 20:07:07 don't summarize, give exact error messages if at all possible Oct 14 20:07:19 also if possible show the values of your SRC_URI and SRCREV Oct 14 20:08:08 Ok so I have the checksums in the .bb file. When I execute bitbake it prints WARNING: Checksum failure and then the error with the calculated checksum. It's different each time Oct 14 20:09:23 SRCREV = "033c3b10197f3a6fc5ddf82ecf226b6d5c1bb208" Oct 14 20:09:23 SRC_URI = "https://github.com/nemomobile/usb-moded.git" Oct 14 20:09:36 it's not using git at all Oct 14 20:09:41 https:// in an SRC_URI will use wget Oct 14 20:09:53 change that to git://github.com/nemomobile/usb-moded.git;protocol=https Oct 14 20:10:11 Ah ok, that might be it. I already wondered about that Oct 14 20:10:41 url scheme determines which bitbake fetcher (and therefore, what underlying tool) is used, not necessarily the actual protocol used to communicate Oct 14 20:11:19 that error you mentioned is about checksumming of fetched *files*, where you set SRC_URI[md5sum] or SRC_URI[sha256sum] to the file checksum Oct 14 20:11:26 Well it is the default checkout url for git on github, so I wrongly assumed it would be smart enough to pull with git. My bad Oct 14 20:11:28 SRCREV is entirely different, pointing to git commits Oct 14 20:11:52 it's understandable confusion, just how bitbake works at this point. the fetcher is pretty explicit Oct 14 20:13:54 Seems to have worked now, not sure about the checksum bits actually being calculated and checked now though. Oct 14 20:14:24 as i mentioned, checksumming is handled completely differently for an scm tool like git Oct 14 20:14:30 it's doing exactly what it should be doing Oct 14 20:15:22 Ok great. I misunderstood you there for a moment. So I can remove those lines. Configure and build seems to work. Now I will just start spending time with the packaging. Oct 14 20:15:46 yeah, SRC_URI[*sum] isn't used at all for git Oct 14 20:16:24 Things have changed a bit in the last few years. I am a bit rusty.. Oct 14 20:18:14 Anyways thanks! **** BEGIN LOGGING AT Wed Oct 15 01:30:49 2014 **** ENDING LOGGING AT Wed Oct 15 03:00:00 2014