**** BEGIN LOGGING AT Mon Mar 31 03:00:00 2014 Mar 31 07:19:08 good morning Mar 31 07:37:56 morning all Mar 31 07:50:31 hi bluelightning Mar 31 07:50:40 hi mckoan Mar 31 09:19:17 is there a common term for bitbake output? i.e Bitbakes bakes recipes and produces ... ? Mar 31 09:20:19 whatever it produces Mar 31 09:20:52 packages, images, pizza orders, sdk tarballs, native tools Mar 31 09:30:20 i remember reading somewhere, in some document, that calling recipes a package is unwise because bitbake produces output packages. I can't find that document right now, but does this ring a bell? that the generic term for bitbake output is 'output packages'? Mar 31 09:33:54 binary packages? Mar 31 09:35:15 'standard' recipes produce one or more binary packages. some recipes are 'special' like image recipe or packagegroup recipes. Mar 31 09:39:27 mago_: naming recipes packages came from old medieval times when OE kept recipes in directory named 'packages' Mar 31 09:50:06 I use the term "output packages" for the output end myself Mar 31 09:50:42 (and "recipes" on the input, naturally) Mar 31 13:52:34 Hi, right before submitting a libomxil patch, I just can't find where libomxil has a commercial license. It seems just LGPL Mar 31 14:58:34 matt10b: LICENSE_FLAGS = "commercial" just means additional licenses may be required for use in a commercial product Mar 31 15:05:51 bluelightning: yes, but I can't find any text refering to it Mar 31 15:06:17 I was wondering if this was still relevant because earlier version have ffmpeg stuff in it Mar 31 15:12:52 matt10b: I'm not sure to be honest Mar 31 15:16:40 ;) Mar 31 15:41:11 https://github.com/kergoth/dotfiles/blob/master/scripts/comm-files rather special purpose, but helpful in comparing two sstate-cache dirs Mar 31 15:41:14 * kergoth yawns Mar 31 16:03:18 e Mar 31 17:18:22 i Mar 31 18:04:53 i couldn't help notice that the style guides from the OE and Yocto sites give conflicting information on what the correct syntax for *.bb files is :-S Mar 31 18:05:10 tlwoerner: right Mar 31 18:05:17 i was hoping someone "in authority" would be able to find the time to look at them and resolve :-) Mar 31 18:05:39 tlwoerner: the rule of thumb is: variables and methods are ordered by time of execution Mar 31 18:06:14 the tabs/spaces difference unfortunate, but it has it reasons Mar 31 18:07:22 koen: okay, this helps. i'm not too worried about "tabs vs spaces" one shows the R* variables at the end, the other shows them towards the top Mar 31 18:07:25 * kergoth ignores the style guide's advice re: tabs/spaces in the layers he maintains. screw tabs Mar 31 18:08:04 tlwoerner: R* is for packages, so between do_install and do_package methods Mar 31 18:08:04 *groan* a standard people ignore is worse than no standard at all Mar 31 18:08:40 aahhhh... so ideally i'd use different rules depending on who i'm submitting it to. okay got it Mar 31 18:09:15 the yocto guide needs to get fixed for R* Mar 31 18:09:38 since oe-core is using "R* after do_install" in reviews anyway Mar 31 18:10:08 which Yocto guide koen ? Mar 31 18:10:22 let's get a bug opened so we don't lose track, we have people working on docs Mar 31 18:10:26 https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide Mar 31 18:10:36 I can see an argument in favor of both orders, really, though practically you're right. given bitbake uses rdepends to influence task order, not just packaging, it can make sense to have it next ot DEPENDS, but in reality most put it with the packaging metadata Mar 31 18:10:37 versus Mar 31 18:10:40 http://openembedded.org/wiki/StyleGuide Mar 31 18:11:23 okay, i'll open a bug Mar 31 18:11:25 I'm trying to debug terminal.bbclass. bb.note() output doesn't seem to show up.. Mar 31 18:11:38 Ah the wiki.... I wonder what our stance is on with bugs and the wiki - I would suggest opening a bug with the Yocto Project, cite the contradiction with URLs and the specific location. Mar 31 18:11:48 thanks tlwoerner Mar 31 18:13:05 kergoth: it's next to DEPENDS for historical reasons, since we did RDEPENDS = "foo" earlier on Mar 31 18:13:14 (which you probably remember vividly) Mar 31 18:15:46 dvhart: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6080 Mar 31 18:16:10 perfect, thanks tlwoerner Mar 31 18:16:31 "the sd-card sized edison will run yocto linux" Mar 31 18:17:12 kroon: bb.note never shows up, not to the console, by deafult it goes to the log files only. use warn if you want to see it on the bitbake ui Mar 31 18:18:39 dvhart: haha yes, while filing the bug i was considering asking about the lack of "web" or "wiki" as a category :-) Mar 31 18:18:55 bb.wiki Mar 31 18:18:55 kergoth, aha, thanks Mar 31 18:18:58 tlwoerner, I added that so it didn't just get closed as "WOBTFIX" Mar 31 18:19:16 kergoth, that's a bug then - it is supposed to go to the console per the logging.bbclass Mar 31 18:19:30 at least, that is the documented API Mar 31 18:20:04 perhaps this is knotty2 that filters these out? Mar 31 18:21:16 first of all, logigng.bbclas is only the shell functions Mar 31 18:21:21 second, it says precisely the opposite of that, "# For the time being, all of these print only to the task logs." Mar 31 18:21:31 so I'm a bit confused Mar 31 18:21:49 :-) Yes I know, I wrote it. It was written to mirror the native bitbake functions. It documents the API Mar 31 18:21:59 it isn't complete (there is a bug open for the shell equivalents) Mar 31 18:22:09 i doubt it's been touched in ages, personally i think the shell functions are pretty useless without talking to the bitbake server Mar 31 18:22:13 and clearly its documentation is out of date Mar 31 18:22:15 but above it was the bb.note() specifically Mar 31 18:22:28 we used to spam the user with everything, its true, but that's no longer the case Mar 31 18:22:32 agreed, the shell functions need to talk to the bb server Mar 31 18:22:52 I have a fix for the shell logging thing, but it still needs work Mar 31 18:23:05 nice Mar 31 18:23:38 I wonder if the "console" output is no longer sufficient. Perhaps we need "knotty" and knotty2 ? Mar 31 18:23:42 https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=paule/shell-logging Mar 31 18:23:47 or perhaps some specifically verbosity setting? Mar 31 18:35:01 dvhart: bitbake has always had arguments to control verbosity ,and to crank up debugging. they're all of limited usefulness right now, so i could see value in having them actually do something useful :) Mar 31 18:36:37 ;) Mar 31 18:37:28 -D is so freaking noisey that it's pretty much pointless to ever use :( Mar 31 18:37:52 need to resurrect our debug domain stuff, it still sort of works, but not very well Mar 31 18:40:46 -D requires redirect to log and post processing, agreed :-) Mar 31 18:53:56 JaMa: I've been spending a little time trying to chip away at your "state of bb world" list, i am working on patches for meta-oe/recipes-support/asio and meta-oe/recipes-extended/mml-widget/gtkmathview Mar 31 19:31:30 JaMa, did you revert my OEDAM update on the wiki on purpose? Mar 31 19:42:18 anyone else seeing these in oe-core master? Mar 31 19:42:23 WARNING: QA Issue: ELF binary '/msp-lpggp1/mhatle/git/oe-core/build-test/tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-qemu/1.7.0-r0/packages-split/nativesdk-qemu/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/qemu-ppc' has relocations in .text Mar 31 19:42:33 I've got a bunch of those from various things when doing a simple Mar 31 19:42:38 bitbae -c populate_sdk core-image-minimal Mar 31 19:42:44 (all of the QA is related to nativesdk packages) Mar 31 19:47:21 My host's (Fedora 20) /etc/bash_completion.d/yum-utils.bash is causing error messages in devshell :-( Mar 31 19:49:34 kroon: mine too (openSuSE) Mar 31 19:49:46 kroon: all my conf/local.conf files include: Mar 31 19:49:51 OE_TERMINAL = "custom" Mar 31 19:49:57 OE_TERMINAL_CUSTOMCMD = "/usr/bin/xterm -e /home/trevor/local/bin/oeshell.sh" Mar 31 19:50:08 /home/trevor/local/bin/oeshell.sh is: Mar 31 19:50:27 /bin/bash --rcfile /home/trevor/.bashrc.oe Mar 31 19:50:56 and /home/trevor/.bashrc.oe is basically my ~/.bashrc but with the problem parts removed Mar 31 19:51:35 kroon, yes -- same here -- but ti doesn't actually cause any failures Mar 31 19:52:27 kroon: see item #26 of https://github.com/twoerner/meta-trevor/blob/master/misc/notes Mar 31 19:54:43 fray, tlwoerner, hmpf.. couldn't this thing be taken care of in upstream oe-core ? Mar 31 19:56:02 it's not oe-core.. Mar 31 19:56:22 it's the shell.. oe-core just runs screen/shell (or similar) and something triggers the failure -outside- of oe Mar 31 20:05:39 ok. i wish oe-cores devshell env. could ignore the host's, and use its own provided "oe-core certified" environment Mar 31 20:06:31 if you did that, you wouldn't get your comfortable development environment there, though :) Mar 31 20:22:29 kergoth, sure.. wouldnt be a problem for me personally though, I usually just use what my distro gives me :-) Mar 31 20:27:53 weirdo ;) Mar 31 20:31:36 ha! Mar 31 20:34:55 seriously though, i wish more software didn't *require* a 9k config file to get working worth a damn Mar 31 20:35:01 * kergoth is a fan of stuff working well out of hte box Mar 31 20:38:17 * Crofton is a fan for more OE builds working out of the box Mar 31 20:40:16 if only :) Mar 31 20:58:41 Crofton: definetely not, shouldn't wiki at least warn when someone submitted something in between? Mar 31 20:59:14 tlwoerner: great, please notice list of local changes I have (was included in my last reply there) Mar 31 21:00:40 Crofton: did you already reverted my change? because only change from me is http://openembedded.org/index.php?title=OEDAM&diff=6965&oldid=6959 Mar 31 21:01:30 I reverted the bit that dropped tlwoerner Mar 31 21:01:48 http://openembedded.org/index.php?title=OEDAM&diff=next&oldid=6979 says you reverted your own changes before that :) Mar 31 21:02:06 It should be OK Mar 31 21:02:12 we ened to work on the agenda some Mar 31 21:02:25 maybe I made a mistake Mar 31 21:02:46 * tlwoerner must remember to be extra-nice to JaMa and Crofton, in case it gets personal (haha!) Mar 31 21:03:05 I figure there are a number of peopl ewho will just show up Mar 31 21:03:12 or are wating on travel approval Mar 31 21:55:40 JaMa: hi, pls note 3.10 will need one more patch for machines using standard/base Mar 31 21:56:01 hopefully 3.14 will be committed soon Mar 31 21:56:14 very soon Apr 01 02:21:13 if i'm cleaning up a recipe, should i remove a PR that doesn't use INC_PR? **** ENDING LOGGING AT Tue Apr 01 02:59:59 2014