**** BEGIN LOGGING AT Wed Jun 10 02:59:59 2015 Jun 10 08:21:15 anyone wish to comment on the following: https://01.org/jira/browse/CM-657 Jun 10 08:21:47 Am I confused or is this a serious invasion of privacy? Jun 10 08:22:42 Is that why it is called connman? It cons you. Jun 10 08:38:55 pompomJuice: AIUI the intention is to have a known good site it can connect to, not for snooping; if you're concerned you can always patch it to connect somewhere else Jun 10 08:39:22 aah ok Jun 10 08:39:32 How do you know it'sa safe Jun 10 09:01:59 I honestly don't, and I don't know the details, but it sounds like it's only around from a short time Jun 10 09:02:54 you could ask for an explanation of why it's been implemented that way if you're still bothered by it Jun 10 09:09:32 morning all btw Jun 10 09:14:31 ok then, good to hear expert advice. Just wanna make sure I understand the landscape. Jun 10 09:18:40 I wouldn't consider myself an expert on connman by any means, although I have written a UI for it (which is probably broken by now, sigh...) Jun 10 09:25:38 i find that connman works fairly brilliantly Jun 10 09:34:22 I am having huge issues controlling my oe:layer's version control. Jun 10 09:35:12 I have a layer wide revision variable that needs to be set so that respected recipies can feed of that REV and check out the correct code. Jun 10 09:36:31 I thought I could achieve this by adding a "require VCS.inc" inside my meta-foo/conf/distro/foo.conf that contains that REV... but every time I change that REV it triggers a full rebuild. Jun 10 09:36:40 Or I suspect so Jun 10 09:36:52 but I cannot tell, from log info or docs what triggers the full rebuild. Jun 10 09:37:24 every time I want to make a small change I have to wait three hours for the result. What am i doing wrong? Jun 10 09:38:45 The way it used to work is that respected recipies would "include foo.inc" which contained the REV... changing REV like so would not trigger a full build. Jun 10 09:38:53 What is the correct way to achieve this? Jun 10 09:40:31 pompomJuice: when you say it triggers a "full rebuild", what is the first thing that starts rebuilding? Jun 10 09:40:37 I went from -> (working) recipy: include foo.inc -> (full rebuild) OE_BASE/conf/local.conf -> (suspected full rebuild again!) meta-foo/conf/distro/foo.conf Jun 10 09:41:03 quilt-native Jun 10 09:41:10 m4-native Jun 10 09:41:18 etc. Jun 10 09:41:24 ok, that definitely should not happen, something strange is going on Jun 10 09:41:29 what are you setting in that inc file? Jun 10 09:42:09 SRCREV = "30333" Jun 10 09:42:17 ok, there's your problem Jun 10 09:42:31 at that level, that will apply to *every* recipe Jun 10 09:42:36 yes Jun 10 09:42:42 that's not what you want Jun 10 09:42:51 is SRCREV a keyword? Jun 10 09:43:13 absolutely yes, the scm fetchers (git, svn, etc.) use it to determine which revision to fetch Jun 10 09:43:15 should I make it TMPREV and then inside the recipies do a "SRCREV = ${TMPREV}"? Jun 10 09:43:35 and it's a dependency of do_fetch thus all fetch tasks are being retriggered, hence rebuild Jun 10 09:43:42 aah Jun 10 09:43:49 it all makes sense noe Jun 10 09:44:13 well, if I were you I'd pick a more specific name relating to whatever makes sense for the recipes that are using it (your company name, name of sw vendor, ...) Jun 10 09:44:20 yea Jun 10 09:44:24 that would make more sense Jun 10 09:44:27 but ultimately it just has to not be SRCREV that you set in the inc file Jun 10 09:44:45 thinks POMPOMREV might work ;) Jun 10 09:44:50 that SRCREV target's a custom fetcher that we wrote for accurev (a VCS system for big corporates) Jun 10 09:44:53 haha Jun 10 09:45:02 write that down! Jun 10 09:46:10 thanks bluelightning Jun 10 09:46:12 np Jun 10 09:47:09 pompomJuice: FYI a slightly different approach to this, still using a common inc file at the config level, is to do SRCREV_pn-recipename1 = "..." SRCREV_pn-recipename2 = "..." etc Jun 10 09:47:23 aaah Jun 10 09:47:37 i was too lazy, those were there. Jun 10 09:47:38 the minor advantage is you don't have to modify every recipe to use the custom var Jun 10 09:47:47 but swings and roundabouts you might say Jun 10 09:48:02 thats the stratigy I am going to make Jun 10 09:48:15 for reference meta-yocto does something similar for tracking: http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/meta-yocto/conf/distro/include/poky-floating-revisions.inc Jun 10 09:48:24 indeed Jun 10 09:48:25 it gives better control over the respective recipy behaviour from one file. Jun 10 09:48:28 I like it Jun 10 12:53:41 layers.o-e.com is out of date: ruby appears to be 2.2.1 but actually it is at 2.2.2 as of : CommitDate: Mon May 11 10:27:28 2015 +0200 Jun 10 12:57:06 bluelightning: ^ Jun 10 12:58:07 hmm, I think there have been some problems updating, I will see what I can do to force an update Jun 10 12:58:30 I'll admit I am not keeping as close an eye on the emails coming from the update script as I used to Jun 10 12:59:48 bluelightning: speaking of the layer index, how does one get perms on a specifc layer? i've been meaning to update the meta-xilinx maintainer details. Jun 10 13:00:30 nrossi: basically you get perms automatically if you create an account and your email matches one of the maintainers of the layer Jun 10 13:00:39 if needed I can add you as a maintainer Jun 10 13:00:49 brb Jun 10 13:01:47 bluelightning: that makes sense since i have perms on the meta-parallella entry. Would you be able to update the email address on the meta-xilinx maintainer to nathan@nathanrossi.com (the xilinx email is invalid now) Jun 10 13:31:08 any comments on the patches I sent about removing distcc and oprofile from the package groups? Jun 10 14:14:23 nrossi: ok, done Jun 10 14:43:13 I seem to be misunderstanding something about stamps. I deleted the stamp files for a certain recipe and re-baked that recipe, but no new stamps were created. In fact, there are no stamps newer than two weeks ago in my stamps directory. I tried deleting all the sstate files related to the recipe and re-baking again, but still no stamps. When are stamps created? Jun 10 14:54:10 consmith: stamps are created when the corresponding task executes (or its setscene equivalent) Jun 10 14:55:26 bluelightning: so if a task runs, a stamp should be created and located in the stamps directory after the task completes? I can't seem to get that behavior Jun 10 14:55:56 that is definitely expected yes Jun 10 14:56:23 if a stamp isn't created then either you aren't looking in the right place or the task isn't actually running Jun 10 15:00:06 I'm pretty sure the task is running because the output from bitbake indicates it, and the sstate cache files are recreated. But no stamp. Perhaps I'm looking in the wrong place, although there are definitely (old) stamps here. What's the easiest way to determine what the stamp directory variable is set to? Jun 10 15:01:44 bitbake -e | grep ^STAMPS_DIR= will show the main stamps directory Jun 10 15:02:03 bitbake -e yourrecipe | grep ^STAMP= should give a partial template for the stamp file name Jun 10 15:03:01 yep just found it. I'm in the wrong directory (facepalm). Thanks for the help Jun 10 15:10:05 is bitbake smart enough to recognize when a task doesn't do any meaningful work? I copy-pasted the install code for a simple recipe into a custom task and added it to the task list, but bitbake said nothing needed to be rerun Jun 10 15:31:55 Crofton|work: Mine keeps failing on kernel configs. Jun 10 15:33:09 I tried the jetson-tk1-l4t machine with the fido branch. Jun 10 15:33:27 liekly it need stuff from master Jun 10 15:33:32 is my guess Jun 10 15:34:07 checkout the master branch of the layers Jun 10 15:35:43 ok. ill give that a shot Jun 10 15:51:45 consmith: when you say you added it to the task list, what did you do exactly? Jun 10 15:53:09 bluelightning: the task was called do_test, so I added the line "addtask test after do_install" Jun 10 16:13:02 I am using OE-Core and meta-oe ... I am receiving http://privatepaste.com/9ee9a7b3f5 Jun 10 16:14:00 it seems bitbake is not liking the 'require' in the layer.conf Jun 10 16:14:04 is it known? Jun 10 16:29:12 Does anyone know if there is an easy way to list installed packages and licenses ? Jun 10 16:31:58 otavio: what's on the line before? Jun 10 16:32:40 realBigfoot: there is a license manifest under tmp/deploy/licenses/ Jun 10 16:33:02 bluelightning, thank you! Jun 10 16:59:39 Crofton|work: No luck. I did 'repo init' to use master and i've tried both jetson-tk1 and jetson-tk1-l4t for machines Jun 10 17:01:25 the first fails with 'no configuration fragments found' and the second fails with 'no rule to make tegra12_defconfig' Jun 10 17:02:05 tegra12_defconfig does exist, but I'm not sure where it's being called. Jun 10 17:16:54 sdh11, I didn't mean use repo Jun 10 17:31:04 This seems new Jun 10 17:31:06 * satisfy_dependencies_for: Cannot satisfy the following dependencies for xf86-video-modesetting: Jun 10 17:31:06 * xorg-abi-video-18 * Jun 10 17:32:41 can investigate in a bit Jun 10 18:07:42 bluelightning_: Jun 10 18:07:55 # Override security flags Jun 10 18:07:58 require conf/distro/include/meta_oe_security_flags.inc Jun 10 18:08:01 two lines **** ENDING LOGGING AT Thu Jun 11 02:59:59 2015