**** BEGIN LOGGING AT Wed Oct 15 03:00:00 2014 Oct 15 08:22:34 gm Oct 15 08:23:22 morning all Oct 15 08:23:29 morning woglinde Oct 15 08:25:49 hm I have a question for alternatives I am not sure that I need _TARGET and LINK_NAME Oct 15 08:26:04 the documentation is a bit cryptic Oct 15 08:27:04 and I see both variants Oct 15 08:28:05 hm okay there is a sentence about using both in the class Oct 15 08:28:25 hmm, do we need to tweak the manual? Oct 15 08:29:03 hm maybe with a example which shows the result Oct 15 08:29:16 but I think I understood it now Oct 15 08:32:48 with target you can install it under another name and with LINK_NAME you link to the alternative you want Oct 15 08:32:57 lsmod recipe helped a bit Oct 15 08:33:39 you need both when you have two packages which installs the file under the same name Oct 15 08:33:50 in the same directory Oct 15 08:36:32 good morning Oct 15 08:37:30 hello mago Oct 15 08:38:51 bluelightning, you mentioned the other day that the best approach to have multiple configs for busybox within the same tree is to create one recipe per config. Should I just copy the busybox .bb-file, or it is possible to just inherit the original recipe and export it as a new name and config (override SRC_URI somehow)? Oct 15 09:28:25 mago_: you can do "require xxx.bb" from another .bb file and then just specify the variable values you want to be different Oct 15 09:29:01 mago_: as long as the other .bb doesn't do anything unusual like setting PN (and I'm pretty sure the recipe for busybox doesn't) then that will work just fine Oct 15 09:33:04 great, that'll work. Is there also a good way to replace a dependency for an image? I'm currently basing my images on core-image, which already depends on busybox. Now I want it to stop depending on busybox and instead depend on busybox-somethingelse Oct 15 09:44:22 mago_: that will be a bit tricky - the problem is that busybox is brought in through a packagegroup (packagegroup-core-boot) Oct 15 09:45:12 so it's probably better to not base my image on core-image? Oct 15 09:45:25 that may make things a bit easier Oct 15 09:46:09 you could try a workaround with RPROVIDES from the alternative busybox recipe but you may find the package manager doesn't handle that in the manner needed to solve this issue Oct 15 10:32:42 really weird, OE seems to be checking out the wrong branch in a recipe Oct 15 10:54:58 ah, no, just ending up in a different ${S} I guess some difference between poky and OE Oct 15 10:55:25 XorA: can you elaborate on what's happening? Oct 15 10:55:52 I can't think of how that particular area would differ in behaviour Oct 15 10:56:58 bluelightning: custome do_compile with oe-core needs a cd ${S} at the beginning but it seems under poky it does not Oct 15 10:57:11 bluelightning: Ive only just worked out myself that is what was happening Oct 15 10:57:49 bluelightning: recipe is git fetcher and has S = ${WORKDIR}/git in it Oct 15 11:02:05 back in an hour or so, going to take me bike out Oct 15 11:10:12 XorA: oh, I think I know Oct 15 11:10:25 XorA: this has to be B != S Oct 15 11:10:43 B is the default dir for most tasks Oct 15 11:11:24 B != S is the default for OE-Core, so perhaps there's a version difference at work there as well? Oct 15 11:12:15 (the default as in what autotools.bbclass does as of a few months ago, and poky doesn't override that) Oct 15 11:25:18 aww, B != S joy and broken autotools packages :/ Oct 15 11:25:28 reminds me of painful days Oct 15 11:56:02 bluelightning: that probably explains it Oct 15 11:56:13 bluelightning: they are non autotooled recipes Oct 15 11:56:38 bluelightning: but they erroneously include autotools class Oct 15 12:04:39 XorA: ah ok Oct 15 12:08:22 bluelightning: Ive had my foot off the pedal with OE for a while :-( Oct 15 12:15:41 how can I control what packages gets built only as ipks (to be installed later using pkg manager)? i noticed everything that is included in an image is always built as ipkgs first, so i guess I could make a "fake" image that I never intend to deploy that includes all packages that I want IPKs for, or perhaps there is a better way? Oct 15 12:19:26 mago_: you can add a "meta" recipe which depends upon the others, basically it should just "inherit meta" and then you just put whatever you need in DEPENDS Oct 15 12:21:16 and then i just bitbake my meta recipe? Oct 15 12:22:50 do you have an example of such meta recipe? Oct 15 12:26:15 yes, just build the meta recipe explicitly and it'll build everything it depends upon Oct 15 12:26:53 not really, all of the recipes I can find at the moment that inherit meta are doing other things as well Oct 15 12:27:21 so what is the purpose of the meta.bbclass? seems to be quite small :) Oct 15 12:32:33 it does two things - ensures that building the meta recipe builds dependencies through to the end, and effectively disables packaging Oct 15 12:33:14 which is all you really need Oct 15 12:33:41 great! **** ENDING LOGGING AT Thu Oct 16 03:00:00 2014