**** BEGIN LOGGING AT Wed Sep 21 02:59:58 2016 Sep 21 06:16:31 Hi, I have a question regarding the expansion of variables. I write a small python function named get_java(d). What it does is it uses bb.utils.which to find java and then prints a note where it was found. If I used this function in my recipe with export JAVA="${@get_java(d)}" the function is executed at parse time. If I don't put the export, the function is not called (I don't see the note). Now my question is there a way to Sep 21 06:16:32 execute the function not at parse time but later for example in the do_configure task? Sep 21 06:58:38 bachp: does the JAVA variable environment variable need to be available to other tasks besides do_configure? Sep 21 06:59:52 Ulfalize (IRC): No in that case I only need it in do configure Sep 21 07:02:01 bachp: you could always export it just within the do_configure task (using the standard ways to export variables in shell/python) Sep 21 07:03:12 exporting it globally in the recipe is usually cleaner though Sep 21 07:03:56 Ulfalize (IRC): I just put the whole expression into the do_configure task and I still see the function being called during parse, however it is also called multiple times later during the execution of the task Sep 21 07:04:53 So if the function get's re-evaluated at the time do_configure is called it's ok because at that point java should be in the path (which is not necessary the case during parsing) Sep 21 07:05:36 bachp: ${}-references in the body of shell functions will be expanded at parse time Sep 21 07:06:03 that in turn yields the final shell task, which is executed later Sep 21 07:06:07 It doesn't seem to be the case Sep 21 07:06:49 the final code, after ${}-stuff has been expanded, is what needs to call the function Sep 21 07:06:56 I see the function called multiple times, first it doesn't find java. Later after the native java package is ready it gets called again and then suddently java is found Sep 21 07:07:10 which might be a bit tricky if it's a shell task and you need to call a python function Sep 21 07:07:19 in that case, see if you can do it in shell instead Sep 21 07:07:24 a global export is probably cleaner though Sep 21 07:08:06 bachp: it'd get called multiple times if stuff needs to be reparsed Sep 21 07:08:16 bitbake sometimes does a lot of reparsing, for whatever reason :/ Sep 21 07:08:30 so for stuff that's called at parse time, you might see lots of calls Sep 21 07:09:32 I just had a look at run.do_configure and I really see the already evaluated path in the do_configure valua Sep 21 07:10:28 Ulfalize (IRC): How can it find java if it is evaluated ad parse time? I mean it should only find it after the DEPENDS have been built? Yet for some reasons the correct path is in the run.do_configure. Sep 21 07:10:58 bachp: maybe it just happened to already have been built Sep 21 07:11:16 No I did a cleanall of both the packages before Sep 21 07:11:35 and I see the function being called and not finding java Sep 21 07:13:43 Ulfalize (IRC): I'm a bit confused now ;) Sep 21 07:14:08 bachp: the files might still be in the staging sysroot. see http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#checking-for-missing-build-time-dependencies. Sep 21 07:15:09 i don't think do_populate_sysroot can be undone Sep 21 07:15:45 btw, it's worth reading the 2.2 version of the manuals if you are reading an earlier version Sep 21 07:16:33 Ulfalize (IRC): Usually I read the "latest" manual :) Sep 21 07:16:52 that'd be 2.1, 2.2 is the upcoming one :) Sep 21 07:22:17 Ulfalize (IRC): I think the latest manual is the same state as the 2.2 manual: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html Sep 21 07:27:31 bachp: heh... looks like it is. not sure why. Sep 21 07:27:36 but not complaining Sep 21 07:28:39 bachp: note that the bitbake manual is not included in the mega manual btw Sep 21 07:29:12 I know Sep 21 07:29:40 just checking :) Sep 21 07:29:53 Thanks Sep 21 07:41:56 rburton, morning! Sep 21 07:42:27 rburton, can you please review my geoclue2 patch? Sep 21 07:42:38 on oe-devel Sep 21 08:36:57 is there a way to disable drag and drop with touchscreen on xorg? I often select text instead of tapping Sep 21 08:48:10 zeenix: not my layer to review for. its likely in the test build which is quite comprehensive and can take a few days Sep 21 08:48:30 rburton, it's been more than a week now Sep 21 08:50:08 zeenix: " geoclue: Update to 2.4.4" is already in mater Sep 21 08:50:10 master Sep 21 08:50:47 oh? Sep 21 08:50:49 meta-oe doesn't mail you when the patch is merged, it's assumed you'll notice when you pull Sep 21 08:50:53 * zeenix feels silly Sep 21 08:51:14 i guess i'm too used to bugzilla.gnome.org Sep 21 08:54:23 rburton, i guess it'll just magically appear on krogoth at some point? Sep 21 08:54:56 zeenix: an upgrade, no. Sep 21 08:55:34 the only upgrades that go into stable branches are things like openssl fixing ten CVEs and the backport would be a nightmare to do correctly Sep 21 09:34:46 hell #yocto Sep 21 09:34:52 s/hell/hello/ Sep 21 09:35:09 quick question, can a recipe in one layer inherit a class from another layer? Sep 21 09:35:15 yes Sep 21 09:35:27 thought so too Sep 21 09:35:30 thanks Sep 21 09:35:45 need to load the layers in correct order/prio perhaps? Sep 21 09:37:22 maybe, for some reason a custom kernel recipe can't inherit kernel.bbclass, or at least some tasks within it, although they appear in bitbake -c listtasks, they cannot be executed i get "ERROR: Task do_shared_workdir does not exist for target virtual/kernel" Sep 21 09:40:59 obsrwr_: maybe it's because you reference virtual/kernel and not the actual linux-xyz recipe Sep 21 09:41:34 even if linux-xyz is the preferred provider? hmmmm Sep 21 09:41:37 * obsrwr_ double checks Sep 21 09:42:31 nope, not the case Sep 21 09:43:10 in some places you should only say shared_workdir and not do_shared_workdir Sep 21 11:36:55 Hi. I've got a recipe that should install numerous assets on the target device. Since this repository might change quite frequently and there are a lot of small files, is there any way to get arround using 'install' for all those tiny files but instead use some kind of wildcard or something similar to cp so i can just copy over the entire directory containing the assets? Sep 21 11:51:57 Anticom: can't install install complete tree structures ? Sep 21 11:52:09 and if not, you can do whatever you want in do_install right ? Sep 21 12:10:57 i'd rather suggest adding a makefile Sep 21 12:11:21 that should provide a make install, so you keep the intelligence on what to do bundled to the sources there. Sep 21 12:16:18 boucman_work: it can? Sep 21 12:16:49 LetoThe2nd: having a makefile to tell bb what js|css|html files to install? sounds kind of odd Sep 21 12:17:00 But maybe i'd go for it nontheless Sep 21 12:18:15 Anticom: why odd? its a package that gets installed. just because its a makefile it doesn't mean it has to compile stuff Sep 21 12:18:38 LetoThe2nd: True Sep 21 12:40:31 Hm this is strange, when i build a CMake project after sourcing our SDKs environment file it's not linking in pthread although it's using boost_thread which should link it in automatically (which also happens if i do a native bulid) Sep 21 12:40:35 any ideas why that is? Sep 21 12:50:21 A compilation of rrdtool in meta-oe fails, due to missing perl module File::Glob. "Can't locate loadable object for module File::Glob in @INC". Is there a missing native-dep here, or is it assumed that this module should be provided by the host system? Sep 21 14:19:28 kergoth: Hi, I know it's offtopic here but i didn't want to pm you. I saw that you've got some vim config files for bitbake. Are they only in your dotfiles or is there a vundle/pathogen plugin for this? Sep 21 14:20:01 Anticom: the official bitbake vim files are in the bitbake git repository, but i have a vim-bitbake repo on my github account for use with vundle/pathogen/etc Sep 21 14:20:39 kergoth: a great, thanks! Sep 21 14:21:29 np Sep 21 15:29:43 Can anyone help me with this error: https://gist.github.com/Anticom/6be55fe1524df83d41cc2535ebd738d9 Sep 21 15:30:19 Anticom: it's telling you the problem. autorev is for use with a branch. set your SRCREV to the tag Sep 21 15:31:51 Didn't know autorev was for branches. It just says in the documentation it points to the latest commit or something like that Sep 21 15:31:59 but thanks :) Sep 21 15:32:06 there is no such thing as a 'latest commit' on a tag Sep 21 15:32:12 a tag is a commit, 'latest' has no meaning Sep 21 15:33:01 hence i thought autrev would work since it's cloned in a detached state, isn't it? Sep 21 15:33:29 again, autorev has no meaning in this context. Sep 21 15:33:36 Okay Sep 21 15:33:52 specifically, AUTOREV refers to a branch, the branch= set in the url, or master Sep 21 15:34:04 so what you're doing there is setting tag= and then setting SRCREV to the top commit of master Sep 21 15:34:08 which is a mismatch, hence the error Sep 21 15:51:24 kergoth: so the way it's usually done when referencing a tag is setting SRCREV to PV? Sep 21 15:52:00 SRCREV should be set to the tag, afaik. Sep 21 16:14:13 Is it possible to provide a build script (CMakeLists.txt in my case) to a project from within a bb recipe? i tried adding it to SRC_URI but CMakeLists.txt is placed outside of git/ directory Sep 21 16:14:35 could i copy it to git/ directory in do_configure_prepend or something? Sep 21 16:14:44 you could do that with SRC_URI Sep 21 16:15:11 ;subdir= Sep 21 16:15:14 yeah thats the one Sep 21 16:15:15 thanks :) Sep 21 16:15:28 i suspect ;subdir=${S} will work too Sep 21 16:16:03 nope. subdir breaks with absolute paths, or at least, it'll blindly join it to workdir Sep 21 16:16:19 we need to fix that, in the meantime you can use inline python. ${@os.path.relpath('${S}', '${WORKDIR}')} Sep 21 16:16:26 iirc, anyway.. Sep 21 16:16:58 hmm Sep 21 16:17:16 ewww Sep 21 16:17:36 presumably we can just throw in an is_absolute() test on the path Sep 21 16:18:25 the "if subdir in urldata.parm" is the only instance of subdir handling right? Sep 21 16:18:47 afaik thats the case Sep 21 16:19:03 just using os.path.join will DTRT Sep 21 16:19:15 if subdir is absolute it throws away the first element Sep 21 16:19:18 would that also override existing files? Sep 21 16:19:20 might be worth adding a comment... Sep 21 16:19:27 ugh, stupid Sep 21 16:19:27 Anticom: you tell us ;) Sep 21 16:19:28 unpackdir = '%s/%s' % (rootdir, urldata.parm.get('subdir')) Sep 21 16:19:33 yeah, os.path.join() will fix it Sep 21 16:19:50 rburton: this would be an interresting way to fix broken build scripts w/o having to wait for PRs to being merged :> Sep 21 16:19:58 rburton: i'll check that tomorrow on another recipe Sep 21 16:29:29 kergoth: i have a patch. *and a test case* Sep 21 16:29:36 nice Sep 21 16:34:44 kergoth: would it be sensible to mandate that the absolute path is a sub directory of the unpack root i wonder Sep 21 16:35:04 probably. we don't want recipes dropping files outside of our workspace Sep 21 16:38:13 bb.fetch2.UnpackError: Unpack failure for URL: 'file://a;subdir=/foo//tmp/tmp_j0zzaap/unpacked/bar'. subdir isn't under root Sep 21 16:38:15 \o/ Sep 21 16:49:08 kergoth: patch on the list if you want to critique it Sep 21 16:49:19 will do Sep 21 16:49:47 one of those little things that was never sufficiently annoying to do anything but workaround. thanks for the fix :) Sep 21 17:36:40 * kergoth fixes the behavior of cooker to stop parsing in the constructor Sep 21 18:18:21 quick question. Is it possible to create a recipe with a LICENSE of "commercial" that does not have a license txt file listed in LIC_FILES_CHKSUM ? Or can I just put an empty LIC_FILES_CHKSUM = "" Sep 21 18:18:59 LICENSE="CLOSED" Sep 21 18:19:10 ah.. thanks. I'll try that Sep 21 18:24:46 https://github.com/openembedded/bitbake/compare/master...kergoth:cooker-no-init-parsing — seem reasonably sane? Sep 21 19:57:22 unreliable file parse ordering is resulting in the order of items in the _remove list changing, which changes the config hash, even though the order of items for that particular flag is irrelevent. i could see it changing for _append/_prepend, the resulting value changes in that case. looking into the root cause of the parsing order change, but we should probably make _remove a set() to sidestep the issue Sep 21 20:00:43 ah, i see. it wasn't my disk, it was a class that was setting _remove with a non-deterministic order. fixing that Sep 21 20:02:02 * kergoth rolls eyes Sep 21 21:04:34 kergoth: did you decide if any of those exception patches should get merged? I ended up a bit confused where we stood with them Sep 21 21:07:21 RP: [PATCHv2 1/2] bb.build: in _exec_task, catch BBHandledException should be merged, hold off on [PATCHv2 2/2] bb.build: in _exec_task, catch errors from TaskStarted, i need to narrow the scope of that exception handler Sep 21 21:07:23 thanks Sep 21 21:10:50 kergoth: thanks, that helps :) Sep 22 02:22:33 yo rburton i had to force-push master but it cleans up all the funky history Sep 22 02:23:23 not just useless merge commits, also some weird duplicate history Sep 22 02:23:56 readme is updated, ready to go public i suppose... **** ENDING LOGGING AT Thu Sep 22 02:59:59 2016