**** BEGIN LOGGING AT Thu Jul 24 03:00:02 2014 Jul 24 03:53:42 I wish FILES_ supported brace expansion as well as globbing Jul 24 05:30:14 *isgh* Jul 24 05:30:25 build for one machine for a while and then change to another MACHINE Jul 24 05:30:25 ERROR: QA Issue: Package version for package avahi-locale-zh-tw went backwards which would break package feeds from (0:0.6.31-r11.1.1 to 0:0.6.31-r11.1.0) [version-going-backwards] Jul 24 07:17:46 good morning Jul 24 07:30:47 gm Jul 24 07:31:03 hi woglinde Jul 24 07:50:26 morning Jul 24 08:21:41 how do i declare an variable that is actually one of options that should be appended to ./configure? like --enable-blahblah Jul 24 08:21:54 i mean in a recipe file Jul 24 08:23:42 jsea, sounds like its PACKAGECONFIG you want Jul 24 08:25:27 jsea, http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PACKAGECONFIG Jul 24 08:25:36 kroon, yeah that delivers the value! thank you so much Jul 24 08:36:05 morning all Jul 24 08:36:24 hi bluelightning Jul 24 08:36:30 hi woglinde Jul 24 08:47:55 kroon, ah I found that it worked by 'EXTRA_OECONF', not by 'PACKAGECONFIG' Jul 24 08:48:02 although thank you for the help again Jul 24 10:49:04 hello guys I am trying to update the pacemaker recipe available into openembedded Jul 24 10:49:21 it needed the add of libqb recipe Jul 24 10:50:38 but I hit a bug into do_qa_configure: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '/media/sdd1/fb/alvd/lxcr-3002/build3/tmp/work/ppc7400-poky-linux/pacemaker/1.1.12-r0/pacemaker-Pacemaker-1.1.12' Jul 24 10:50:59 I investigated config.log Jul 24 10:52:28 at what point does bitbake copy SRC_URI files into ${S} ? Jul 24 10:53:18 there are quite more enough "unsafe for cross-compilation'" there which are identified by the insane.bbclass Jul 24 10:53:43 mago_: do_fetch Jul 24 10:59:09 i'm trying to get bitbake to copy some out-of-tree C files into my ${S}, but they seem to not be copied. Are there any special rules for .c files? if I change it to a non-existing file, it stops with an error. So clearly it acknowledges the entry in SRC_URI, but for some reason it doesn't get copied to ${S} like I expect Jul 24 10:59:34 (and i'd prefer to not put in these C-files as patches) Jul 24 11:06:13 mago_: I think you may find that they won't be copied into ${WORKDIR} until do_unpack Jul 24 11:33:58 mago_: They will go into ${WORKDIR}, not ${S} at do_unpack fwiw Jul 24 11:34:20 ah, yes, thank you. my mistake! it works now Jul 24 12:02:36 mago_: argh... sorry that was *my* mistake ;-) Jul 24 12:04:08 I am trying to create a generic recipy base.inc that contains the following for all our apps ---> RDEPENDS_${PN} += "versioninfo-package (>= ${IMAGE_BUILDNR})" Jul 24 12:04:14 is this the right way to achieve this? Jul 24 12:04:28 when I do that bitbake gives me a strange warning Jul 24 12:05:49 WARNING: Variable key RDEPENDS_${PN} (... all packages that include base.inc here...) replaces original key RDEPENDS_one-of-those-packages ( versioninfo-package (>= ${IMAGE_BUILDNR})). Jul 24 12:05:52 that is the warning Jul 24 12:06:33 pompomJuice: are you perhaps setting RDEPENDS_ = in the recipes themselves? Jul 24 12:06:41 yes Jul 24 12:06:44 after that one Jul 24 12:06:45 mmm Jul 24 12:06:50 should it always be += Jul 24 12:06:52 let me check Jul 24 12:06:59 then change that to RDEPENDS_${PN} instead Jul 24 12:07:22 will do Jul 24 12:08:05 or at least ${PN} based i.e. if the recipe is called bob then use RDEPENDS_${PN}-dev rather than RDEPENDS_bob-dev Jul 24 12:08:18 ok Jul 24 12:09:46 d.setVar("RDEPENDS_${PN}", " ".join(packages)) Jul 24 12:09:48 that line Jul 24 12:10:09 must be changed to append to RDEPENDS, not nuke it and start over Jul 24 12:10:27 damn I wish I was comfortable with python Jul 24 12:10:36 such a drawback with this bitbake stuff Jul 24 12:10:54 d.setVar("RDEPENDS_${PN}", RDEPENDS_${PN}.join(packages))? Jul 24 12:11:32 one-of-those-packages contained the servar, that is what the warning was about Jul 24 12:11:38 bitbake saw that I was nuking the variable Jul 24 12:11:53 it protectss me against myself.... very good :) Jul 24 12:12:35 pompomJuice: I think what might be happening there is that ${PN} is getting expanded before the function runs Jul 24 12:12:50 aah Jul 24 12:14:48 d.setVar("RDEPENDS_${PN}", "${RDEPENDS_${PN}}".join(packages)) Jul 24 12:14:55 that line seems to be building... Jul 24 12:15:04 does it look like it does a concat? Jul 24 12:15:17 does .join make a space? Jul 24 12:15:25 that is not correct I'm afraid Jul 24 12:15:36 im sucha python noob Jul 24 12:15:50 it looks odd but what you call join on is the separator Jul 24 12:15:54 I have no idea where bitbake/bash starts and python ends in this bitbake system Jul 24 12:16:05 so " ".join(...) joins the elements with a space Jul 24 12:16:18 oh Jul 24 12:16:19 I see Jul 24 12:16:32 it packs them out each with a space in between? Jul 24 12:16:50 yes, if you call it on " " Jul 24 12:16:58 oh my Jul 24 12:17:01 if you called it on ":" it would join them with a colon Jul 24 12:17:04 my guessing was way off Jul 24 12:17:15 what is the python for Jul 24 12:17:15 but changing that isn't going to help with the issue you're having Jul 24 12:17:52 take whatever is in RDEPENDS_${PN} and join to it what is in packages that is seperated with that .join move Jul 24 12:18:02 no Jul 24 12:18:17 is that not wat I want? Jul 24 12:18:41 oh, if you're describing what you want, yes, sorry... I thought you were describing what it currently does Jul 24 12:18:44 the package that is giving the issue has a anonymouse python part that manually rigs the RDEPENDS Jul 24 12:19:07 it rigs with setVar Jul 24 12:19:12 I want to concatVAR Jul 24 12:19:19 how? Jul 24 12:19:31 use appendVar ? Jul 24 12:19:35 well Jul 24 12:19:37 as I said Jul 24 12:19:40 noob alert Jul 24 12:19:42 but whilst that might be desirable that isn't the issue Jul 24 12:19:42 let me try that Jul 24 12:19:55 the issue as I mentioned before is that ${PN} is getting expanded before the python code runs Jul 24 12:20:14 aah Jul 24 12:20:15 I see Jul 24 12:20:37 ok but that pyton code is not in the base class Jul 24 12:20:41 or the base.inc Jul 24 12:20:48 it is inside one of my recipies causing the warning Jul 24 12:21:10 WARNING: Variable key RDEPENDS_${PN} ... replaces original key RDEPENDS_ctlab-android-apps Jul 24 12:21:26 yes, the issue is that those are interacting poorly Jul 24 12:21:28 appendVar still triggers the warning Jul 24 12:21:32 right, it would Jul 24 12:22:01 my tactics works for all the other recipies, just this one with the manual rigging Jul 24 12:22:30 there are a number of ways of fixing this Jul 24 12:22:36 yes... Jul 24 12:22:59 a quick hack would be to do something like d.setVar("RDEPENDS_$" + "{PN}", " ".join(packages)) Jul 24 12:23:44 testing Jul 24 12:24:43 does the same Jul 24 12:24:48 let me show the proper warning Jul 24 12:25:01 WARNING: Variable key RDEPENDS_${PN} (ctlab-osprey-android-preferences ctlab-osprey-android-configuration ctlab-osprey-android-deletedata ctlab-osprey-android-demomode ctlab-osprey-android-export ctlab-osprey-android-pqevents ctlab-osprey-android-realtimeview ctlab-osprey-android-start ctlab-osprey-android-syseventlog ctlab-osprey-android-timedrecording ctlab-osprey-android-launcher) replaces Jul 24 12:25:02 original key RDEPENDS_ctlab-android-apps ( duo-version (>= ${IMAGE_VERSION})). Jul 24 12:25:12 it notices that I replace the bottom version with the top one Jul 24 12:25:15 I want to append Jul 24 12:25:21 appendVar does not work Jul 24 12:25:27 your trick also Jul 24 12:25:30 but its a warning Jul 24 12:25:33 maybe it does work Jul 24 12:25:38 the warning might be skew Jul 24 12:26:30 no, what it says *is* happening Jul 24 12:26:56 oh my Jul 24 12:26:56 hehe Jul 24 12:27:02 the problem is that you're effectively setting two different variables that get combined into one later Jul 24 12:27:17 and one just stomps on the other's value, hence the warning Jul 24 12:27:36 I dont want stomping Jul 24 12:27:42 I want to combine Jul 24 12:27:45 no, which is why you need to fix the issue Jul 24 12:28:04 the duo-version one I want appended to whatever is already in RDEPENDS_${PN} for that recipy Jul 24 12:29:04 I see this convention in my recipy ->>> python __anonymous () { Jul 24 12:29:14 what does that do? Jul 24 12:29:17 where does it hook in Jul 24 12:29:48 it just gets run during parsing Jul 24 12:29:57 before or after Jul 24 12:30:08 http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#anonymous-python-functions Jul 24 12:33:12 I might have a solution Jul 24 12:34:20 basically specify another variable in the anon python that is used inside the recipy to do the combine there with a += Jul 24 12:34:42 your anon python documentation fixed the problem Jul 24 12:34:56 yep, that's another way to do it Jul 24 12:34:57 now I understand how that works Jul 24 12:35:15 thanks man Jul 24 12:47:38 i don't fully understand how to manage my patches with bitbake. lets say i make a patch (#1). now, i want to make another patch (#2), so i enter the ${S} dir (which is a git repo in my case). It is dirty, since patch #1 has been applied. am I suppose to make my changes and create a new patch to replace #1, or should I first do a dummy commit of the dirty tree, make my changes, commit it and finally generate #2? if I have like 5 patches on a repo, t Jul 24 12:47:38 his process becomes quite frustrating .. Jul 24 12:48:41 the way I do it is as follows Jul 24 12:48:45 bitbake foo -c patch Jul 24 12:48:50 go to the workdir Jul 24 12:49:00 quilt new somepatch.patch Jul 24 12:49:04 quilt add somefile Jul 24 12:49:10 edit somefile Jul 24 12:49:14 quilt refresh Jul 24 12:49:25 copy the somepatch.patch file to your recipies Jul 24 12:49:39 anything else is going to be hard Jul 24 12:49:41 yes, that's the right way to do it, actually. Jul 24 12:50:01 bitbake will manage/apply patches with quilt. so all quilt commands should work Jul 24 12:50:12 exactly Jul 24 12:52:27 now that I think of it Jul 24 12:52:39 there might be order issues Jul 24 12:52:53 I have seen people prefix their patches to fix that Jul 24 12:52:59 so rather Jul 24 12:53:08 quilt new 20_foo.patch Jul 24 12:53:18 when your resipy contains 19 patches already Jul 24 12:53:25 and they are all prefixed Jul 24 12:54:47 but that is only neccesary when you patch one file with two different patches somehow Jul 24 12:55:06 so all should be well Jul 24 12:56:48 pompomJuice: patches are not applied based on their filename, but based on the order in SRC_URI Jul 24 12:57:03 aah Jul 24 12:57:07 makes sense Jul 24 12:57:46 and usually new patches go to the tail end Jul 24 13:50:51 dont we have anything for automatic perl modules deps ? Jul 24 13:51:00 it's just plain hell as it is :/ Jul 24 13:51:23 (hello nonetheless :) Jul 24 14:00:14 bencoh: right, it's a known problem... we've discussed fixing it over the years but nobody has had time to dig into it beyond that Jul 24 14:00:47 I guess nobody ever tried to include datetime-format-iso8601 :D Jul 24 14:48:31 Hey all. Having trouble locating the problem: kernel modules aren't getting stripped. (Dora) Jul 24 15:01:38 anyone knows why bitbake still selects libav as libpostproc provider (instead of separate recipe)? Jul 24 15:01:41 NOTE: preferred version 9.13 of libav not available (for item libpostproc) Jul 24 15:01:43 NOTE: versions of libav available: 0.8.11 Jul 24 15:02:07 building just libpostproc selects right provider Jul 24 15:02:21 but DEPENDS from some other recipe still selects libav Jul 24 15:06:51 JaMa: see comments in e8f9420 Jul 24 15:08:23 BBL Jul 24 15:10:18 there is also libpostproc package incorrectly in libav-9 PACKAGES_DYNAMIC http://lists.openembedded.org/pipermail/openembedded-core/2014-July/094404.html Jul 24 15:10:26 but the warning is still there :/ Jul 24 15:52:40 No thoughts on kernel modules not being stripped? Jul 24 16:26:14 denix: around? i am doing an oe-core + meta-ti build for BBB. noticed that 'kernel' package is not included by default, as such the board doesn't boot with all default generated files. Jul 24 16:26:23 is that really intentional? Jul 24 16:35:38 moin Jul 24 18:18:34 man, tantalizingly close to getting a functional toolchain from my newly restructured meta-sourcery with split-recipes Jul 24 18:20:20 Quick question: Is it possible to know at build time which version of tar will be used in the image (busybox or GNU)? Jul 24 18:20:45 depends on what image you're building, and how your busybox is configured Jul 24 18:22:23 The use case is that in udev-cache, I'd like to be able to use the "--exclude=log" option to tar, which exists in GNU tar but not busybox tar Jul 24 18:23:10 We've broken the tar arguments into a parameter in meta/recipes-core/udev/udev/udev-cache.default like this: Jul 24 18:23:20 DEVCACHE_EXTRACT_OPTS="--exclude=log -m" Jul 24 18:23:54 but we'd like the ability not to use the --exclude=log argument if the system tar doesn't support it, and ideally, we'd like to find that out at build time rather than having to check the version in the initscript. Jul 24 18:47:33 ndec: see item #4 here http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/README.hardware#n190 Jul 24 21:48:37 denix: nice! it was documented properly! i guess this is equivalent to simply add 'kernel' in the image which is what i am doing.. Jul 24 21:49:39 ndec: it actually gets into the image automatically. the exception is core-image-minimal, because that doesn't follow the rules... Jul 24 21:50:15 aren't rules meant to be broken? Jul 24 21:50:53 ndec: heh :) **** ENDING LOGGING AT Fri Jul 25 03:00:00 2014