**** BEGIN LOGGING AT Mon Jan 18 02:59:58 2016 Jan 18 08:57:25 good morning Jan 18 13:25:21 gm Jan 18 16:05:20 can i tell which sstate-file is used to speed up a certain task? Jan 18 19:44:32 where should qwt go in the new meta-qt4 Jan 18 22:45:19 bluelightning, I need to start adding recipes to meta-qt4 Jan 18 22:45:25 where shoudl qwt go? Jan 18 22:46:15 Crofton|work: we could add qwt there I suppose Jan 18 22:46:39 we need to p[ick up the qt4 stuff dropped from meta-oe Jan 18 22:46:52 I thought that was where we were supposed to move it Jan 18 22:47:43 I've got a handful of things that fell out of meta-oe due to the qt4 drop Jan 18 22:48:16 pyqt willalso need a home Jan 18 22:53:25 bluelightning, also, toaster is confusing the crap out of me now :( Jan 18 22:54:23 we could always create a meta-qt4-extra if meta-qt4 wasn't appropriate Jan 18 22:54:47 Crofton|work: what in particular in Toaster? Jan 18 22:57:08 well, I think extra isn't rellly needed, we just need to put stuff in meta-qt4 and hope people move to 5 Jan 18 22:57:22 extra is too vague, Jan 18 22:57:24 well, I got it started in my build area and it wants me to add layers Jan 18 22:57:43 it look like put all junk here Jan 18 22:58:06 we just need to add the stuff peop eluse to meta-qt4 Jan 18 22:58:32 like my utility company gives me a 35G can and then extra I can leave on curve for them to pick up Jan 18 22:58:38 obviously I nag the gnuradio guys to get to qt5 every chance I get, but unitl they do I need to use meta-qt4 Jan 18 22:59:23 Crofton|work: ok, thats a valid case then. but I guess you gotta fix it Jan 18 22:59:39 yeah, I need to add stuff gnuradio uses Jan 18 22:59:43 and also you get to have packages in there which interests your project Jan 18 23:00:04 I'll only submit qwt, not qwt-e, but leave .inc file in case someone uses the other case Jan 18 23:00:39 I guess both can go in Jan 18 23:00:40 make sense Jan 18 23:00:50 I ahve no way to test the -e one Jan 18 23:00:59 thats fine Jan 18 23:01:09 as long as its just a move Jan 18 23:01:11 I'd rather we only move stuff that has known users Jan 18 23:01:29 it can confuse folks Jan 18 23:01:35 if its spread Jan 18 23:01:38 main question is ther eis not dir in meta-qt4 for libs Jan 18 23:01:38 over layers Jan 18 23:01:45 what should I call it it? Jan 18 23:02:01 recipes-libs Jan 18 23:02:10 that is why I'd like to carry all 1t4 stuff in one place Jan 18 23:02:10 deal Jan 18 23:03:11 I'll start preparing patches for stuff I need for gnuradio Jan 18 23:04:05 ok Jan 18 23:07:55 It will be intersting to see what they are :) Jan 18 23:18:18 I need to fix my gnuradio build and do not want to carry qt4 stuff anywhere except meta-qt4 Jan 18 23:18:29 so wehn gnuradio goes qt5 I can cleanly drop one layer Jan 19 00:42:46 Crofton|work: is QT5 on radar for GNURadio ? Jan 19 00:44:56 yes, although much beatin will be required Jan 19 00:46:54 ok Jan 19 00:49:01 khem: "it look like put all junk here" - well, that is kind of what we've been doing with meta-oe... Jan 19 00:49:37 bluelightning: do you mean meta-oe ? Jan 19 00:49:55 meta-openembedded as repo is well organised Jan 19 00:50:18 I meant meta-oe the layer Jan 19 00:50:19 ideally meta-oe should dissipate into other layers Jan 19 00:50:32 I agree Jan 19 00:50:45 yep, that would be the preferred outcome for me as well Jan 19 00:50:58 obviously it's hard to find categories for everything (and interested maintainers) Jan 19 00:51:13 however, its work Jan 19 00:51:17 but meta-qt4 shoudl go away at some point Jan 19 00:51:36 at least in my case :0 Jan 19 00:52:02 the end game is layers with one recipes, which we want to avoid Jan 19 00:52:51 if you were to go to the point of absurdity yes ;) Jan 19 00:53:06 but that wouldn't make any sense Jan 19 00:53:44 :) Jan 19 00:56:04 Crofton|work: there always will be overrides Jan 19 00:56:31 its understood you dont want to parse 700 new recipes to get 1 into your project Jan 19 01:30:25 bluelightning: I am trying to test out devtool workflow as a novice :) Jan 19 01:30:37 khem: great - how is that going? Jan 19 01:31:11 bluelightning: so here is what I did Jan 19 01:31:13 devtool create-workspace ~/hacking Jan 19 01:31:27 devtool status Jan 19 01:31:39 NOTE: No recipes currently in your workspace - you can use "devtool modify" to work on an existing recipe or "devtool add" to add a new one Jan 19 01:31:47 devtool modify fbset Jan 19 01:31:54 ERROR: directory /home/ubuntu/hacking/sources/fbset does not exist or not a directory (specify -x to extract source from recipe) Jan 19 01:32:21 so there seems to be a inconsistency Jan 19 01:32:28 in what Note says Jan 19 01:32:58 it should also include extract step somewhere Jan 19 01:33:01 devtool modify expects source to exist already, unless you use -x (which you need to in this case) Jan 19 01:33:16 upon reflection I think I should have made that the default behaviour Jan 19 01:33:35 exactly my point Jan 19 01:35:04 it should check if src is not extracted Jan 19 01:35:13 the do so Jan 19 01:35:38 also, FYI, no need to use devtool create-workspace unless you don't like the default path Jan 19 01:36:23 bluelightning: yes, I am playing proxy on behalf of others :) Jan 19 01:36:42 I have made changes using devtool in past with no issues Jan 19 01:37:22 ah ok I see Jan 19 01:37:42 so beyond changing the default behaviour of devtool modify do you have other suggestions? Jan 19 01:37:48 so once I set up with -x say Jan 19 01:38:07 the I can use bitbake or devtool to orchestrate the build right ? Jan 19 01:38:55 yes Jan 19 01:41:10 another small issue I see is that temp/ folder is still in TMPDIR Jan 19 01:41:33 if now I have to look at compile logs Jan 19 01:42:38 so I can not cd into the newly set workspace and find everything in there Jan 19 01:43:16 hmm, ok... we could set up some symlinks Jan 19 01:44:30 I'd like to see externalsrc move WORKDIR or T relative to S :) Jan 19 01:44:37 in general, for devtool & otherwise Jan 19 01:48:04 if we're going to move anything we might as well move the WORKDIR I suppose Jan 19 01:49:21 no may be just symlink it Jan 19 01:50:21 the run.do_* script are independent of where they are run Jan 19 01:54:25 bluelightning: another nice-to-have would be to not require in all cmds if there is only 1 package being worked-on Jan 19 01:54:43 or something like devtool workon cmd Jan 19 01:55:13 and then devtool would insert the whereever its required Jan 19 01:56:27 hmm... possibly; I wouldn't want people to get confused about the context they were in though Jan 19 01:57:09 I can appreciate typing it out every time is tedious Jan 19 01:57:28 I was hoping to alleviate that through bash completion - there is a bug open to implement that Jan 19 01:57:29 If you want something like that, I'd add an env var it obeys, and possibly add a sourced shell script to provide functions to manipuate it Jan 19 01:57:35 not unlike virtualenv and pyenv and the like Jan 19 01:57:42 * kergoth shrugs Jan 19 01:58:00 then the context could be easily added to the prompt Jan 19 01:58:15 that would be another alternative yes Jan 19 01:59:10 could add an env var to recipetool for the layer too, that's another case where you have to keep passing it even if you're doing all your work in your own layer Jan 19 01:59:19 end up with a lot of positional arguments Jan 19 02:03:31 bluelightning: another nice-to-have is that when we use update-recipe, then it should prioritize PN-PV recipe Jan 19 02:03:50 err I mean PN-PV dir to house patch over PN Jan 19 02:04:36 I guess I went with convention on that one, we tend to use PN more often than PN-PV Jan 19 02:04:49 some of these things could also be implemented as a config file option Jan 19 02:05:04 just depends on whether it's preference vs. the right behaviour Jan 19 02:05:45 bluelightning: I guess its not must Jan 19 02:06:01 since its placing a patch in a valid dir anyway Jan 19 02:06:18 and usually we have 1 version of packages now a days Jan 19 02:06:22 I did think about perhaps looking at where most of the existing files in SRC_URI were and using that dir instead of always using PN Jan 19 02:06:23 so not a big deal Jan 19 02:06:58 bluelightning: there seems to be no general logic that can be cleanly assumed Jan 19 02:07:09 unfortunately not in this case Jan 19 02:07:38 I'm all for making the tools smarter where there is though, naturally Jan 19 02:09:20 someone should write a frontend to drive devtool from eclipse :) Jan 19 02:10:02 it's definitely been discussed, I'm not sure when it will happen, but it's on the cards Jan 19 02:10:48 at least, some folks here at Intel would like to see it implemented Jan 19 02:13:04 bluelightning: when doing recipe-update it would also be nice to emit a note saying that you are still plugged into externalsrc if you are done then do something Jan 19 02:13:54 right yes, at the back of my mind I've been a little bit uncomfortable with how it leaves you at that point Jan 19 02:15:14 and sync cmd bails our without srctree mentioned on cmdline Jan 19 02:15:28 that could be changed to default to workspace Jan 19 02:15:45 yes, sync was a bit loosely implemented Jan 19 02:16:23 think of recipes with no patches for OE Jan 19 02:16:26 it has to do with whether or not it's supposed to be used with recipes in the workspace... it wasn't firmly decided Jan 19 02:17:00 may be sync-src Jan 19 02:17:01 there's also the issue of devtool update-recipe after devtool-add... it works just fine, but unlike with the devtool modify the recipe is still in the workspace and you need to do another step to move it out to your own layer, you can't just do devtool reset at that point Jan 19 02:17:04 is better option Jan 19 02:17:23 Slightly OT, but I was thinking earlier about adding a recipetool option or command to create a recipe with no source specified -- that is, just write a template to the layer and let me edit it, a recipe equivalent of newappend, would that be of use to anyone? Jan 19 02:18:43 kergoth: what does it buy ? Jan 19 02:18:54 not sure... I can't see myself using such a thing - I'd rather have the tool fill in as much as it can, even if that only amounts to LIC_FILES_CHKSUM it's saved me some work Jan 19 02:21:24 bluelightning: I will play with upgrade cmd tomorrow Jan 19 02:21:50 khem: ok... I haven't had a lot of feedback on it so I don't know how many people have used it up to now Jan 19 02:23:49 bluelightning: undeploy-target and deploy-target will undeploy-target recover the old versions ? Jan 19 02:24:00 I'm afraid not Jan 19 02:24:14 hmm then whats the purpose of this option Jan 19 02:24:51 removing all traces of files it deployed Jan 19 02:25:13 so say I am debugging fbset Jan 19 02:25:24 and I deployed the one I built with my changes Jan 19 02:25:31 it worked ok Jan 19 02:25:36 and I undeployed it Jan 19 02:25:45 now it fbset gone from target ? Jan 19 02:25:48 yep Jan 19 02:25:52 if we were to implement a solution that did so wouldn't you need to keep a stack of old files rather than just one set, assuming that you can repeatedly deploy? Jan 19 02:26:07 hmm Jan 19 02:26:21 maybe not, maybe we just keep the first set Jan 19 02:26:33 so undeploy should be masked then since it will leave the target in bad state Jan 19 02:26:44 masked how? Jan 19 02:26:59 thinking of a lab scenario Jan 19 02:27:28 a target may be used by more than 1 developer or same dev debugging two different problems Jan 19 02:28:00 bluelightning: do not remove the packages from target Jan 19 02:28:07 when undeploy is done Jan 19 02:28:31 undeploy wouldn't do anything then Jan 19 02:28:43 if it's to put anything back there needs to be something to actually put back Jan 19 02:29:07 I'm all for improving this but we need to come up with behaviour that practically works Jan 19 02:29:57 so it should create a overlay Jan 19 02:30:08 during deploy Jan 19 02:30:21 anyfile its replacing. Make a copy of it Jan 19 02:30:29 may be in same folder tree Jan 19 02:30:32 structure Jan 19 02:30:41 say under /devtool/ Jan 19 02:30:47 what if space is at a premium on the device? Jan 19 02:30:47 on rootfs Jan 19 02:31:26 I guess we would have to check space first and complain, and provide an option to not preserve Jan 19 02:31:34 yeah Jan 19 02:35:29 you need that anyway Jan 19 02:35:36 because new binary may be bigger in size Jan 19 02:35:47 or bigger due to debug info being not stripped Jan 19 02:35:48 and so on Jan 19 02:37:21 khem: primarily recipes which are either meta or which provide scripts, and therefore have no external sources to analyze Jan 19 02:37:30 but admittedly that might not be that common a case Jan 19 02:38:45 kergoth: right **** ENDING LOGGING AT Tue Jan 19 02:59:58 2016