**** BEGIN LOGGING AT Mon May 02 02:59:58 2016 May 02 08:13:37 good morning May 02 08:43:27 while attempting to open devshell I get Error:https://paste.kde.org/pjzpmytke ... any clue? May 02 09:00:06 Nilesh_: No space left on device May 02 09:01:07 mckoan: its 16gb though May 02 09:03:07 is that not enough? May 02 14:06:58 Hrm. I guess setcap doesn't working in pseudo? May 02 15:50:55 hmm, who exactly apart from the kernel itself may depend on "kernel-base"? I can May 02 15:50:59 't find it May 02 15:51:04 tried -e and such May 02 16:34:52 is calix.com spamming anyone else besides me ? May 02 16:35:47 I understand you are using a review system but configure it properly please !! May 02 17:25:16 Is someone willing to review some Wayland rework patches to support XWayland? May 02 17:26:28 that sounds nice. id on't know enough about wayland to review it, though :) May 02 17:27:13 Anyone want to take a quick glance at my wks.in prototype? I'm mainly looking for a yes/no on whether this direction is completely crazy or not, before I submit the RFC patches to the list -- https://gist.github.com/kergoth/630fc46f774281fd68c82fb9492e0bf8 May 02 17:27:36 i think it has value, not hardcoding things like serial console tty in the .wks file for wic would be nice May 02 17:27:37 heh May 02 17:32:46 kergoth: agreed however I'd name .in files as bbin or similar May 02 17:32:55 .in means autoconf for me May 02 17:32:56 kkk May 02 17:33:50 it's a pretty common convention for generated files to go from .in -> no .in, even outside of autoconf. i.e. foo.pc.in -> foo.pc. but it's a fair point, given it's using bitbake variable expansion rather than some other templating mechanism, .bbin or similar could make sense May 02 17:34:44 i thought about leveraging some other templating scheme, but it'd mostly end up translating metadata variables to template fields anyway, so seemed a pointless indirection :) May 02 17:35:29 agreed and using a bb.in schema makes sense May 02 18:18:31 khem, I got the spam too. everyone in commits to oe May 02 18:18:57 we should ask them for $$$. they are using OE May 02 18:21:05 otavio: sure I can review it May 02 18:21:22 armpit: yeah would be good for folks to support the project May 02 18:21:38 khem: great! https://www.dropbox.com/sh/vx1qlei0hl5gxe0/AACElM_DnSepXE6gUT7bbUvAa?dl=0 May 02 18:22:10 khem: I will be sending it tomorrow but a pre-patchset review would be nice so we avoid many revisions May 02 18:23:46 otavio: 0002-weston-Remove-XWayland-dependencies-on-PACKAGECONFIG.patch why remove DEPS May 02 18:24:35 hmm I see so we have it covered with x11 DISTRO_F May 02 18:25:27 khem: yes; it avoids duplication and removed the need to keep it in sync May 02 18:25:40 khem: also it is pointless as the x11 is required anyway May 02 18:26:15 use export XDG_RUNTIME_DIR=/var/run/user/`id -u`/ May 02 18:28:38 patchset looks good elsewhere May 02 18:32:13 khem, I just sent a note about calix to the advocacy team to go chase the lead May 02 18:32:44 +1 May 02 18:34:09 khem: great May 02 18:34:13 also send a note to calix on spam, that would be preferred May 02 18:37:15 khem: fixed 0002 May 02 18:37:19 khem: please take a look May 02 18:38:31 https://jobs-calix.icims.com/jobs/3280/senior-software-engineer---embedded---platform/job May 02 19:40:44 hey. can anyone explain the relationship between poky and openembedded core? i was under the impression that poky is a reference distro ontop of oe-core, yet when i look at the poky repo (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/) i see it has its own copy of both bitbake and oe-core (poky/meta dir). Why are these not submodules? it seems like they have been "copied" into poky, so essentially a fork of May 02 19:40:45 oe-core and upstream bitbake? May 02 19:41:09 poky is both a reference distro and a repository which is an integration of components May 02 19:41:19 the poky repo is oe-core + bitbake + meta-poky/meta-yocto May 02 19:41:21 submodules are a pain to deal with.. so Poky has decided to include a copuy of the components.. May 02 19:41:39 i think the confusion sets in because the components aren't structured the same May 02 19:41:40 if you look at the git tree the copy is commented to the oe-core (and bitbake) commit ids.. May 02 19:41:45 i.e. it's meta, not oe-core/meta in poky.git May 02 19:43:00 seems like a really weird way of doing it, essentially cherry-picking each commit from oe-core into poky? May 02 19:43:20 it's all automated May 02 19:43:21 it's actually fairly common May 02 19:43:28 and I agree.. it is fairly common.. May 02 19:43:31 there are a lot of tools for puling vendor or third party sources directly into a git repo May 02 19:43:33 the hatred for submodules is far and wide May 02 19:43:39 if you don't want to, there are tools like submodules, repo, or mr May 02 19:43:53 if you do, there are tools like combo-layer, git-subtree, git-subrepo, piston, braid, peru, etc May 02 19:44:02 ya.. in the OE/YP world, I'm using to seeing 'repo' and just direct inclusion.. May 02 19:44:07 (combo-layer effectively) May 02 19:44:21 there's some use of submodules too, but mostly dabblers, not projects May 02 19:44:32 kergoth: are you saying poky/meta isn't just a certain rev of oe-core/meta? May 02 19:44:34 ya, I've never seen anyone use submodules for real projects.. May 02 19:44:44 mago__: no, that's exactly what it is May 02 19:44:45 poky/meta tracks oe-core/meta.. May 02 19:44:51 k May 02 19:45:01 and again, there a ton of tools to do this, including external sources directly in a local repository May 02 19:45:01 (i use repo myself) May 02 19:45:15 the value is it's truly self-contained, and you don't have to deal with teh overhead of submodules May 02 19:45:21 however, submodules have the problem where you have to constantly update them -- and just pulling one tree doesn't give you the info you need... so you have to pull it all down.. it's painful and easy to screw up May 02 19:45:31 yeah, the overhead of updating the main repo every time is a pain May 02 19:45:35 which is where repo comes in, since it can track branches May 02 19:45:54 product I work on is based on bitbake/oe-core/meta-yocto(poky)/etc.. but we keep it seperate, and do somethign similar to repo May 02 19:46:05 kergoth, exactly.. tracking branches is the useful part.. May 02 19:46:13 personally, i like to use repo for components of a single project, where they're being actively developed, and something like subtree/subrepo/combo-layer for vendor / third party sources for my projects, so i'm less reliant on them, an dupdate overhead is less of an issue May 02 19:46:23 but everyone has their workflow preferences.. May 02 19:46:32 yup May 02 19:47:27 e.g. i use peru (not unlike braid/piston/subtree/subrepo, just not bound to the scm) for my dotfiles, for example. those are largely unchanged from upstream and i don't update them enough for the overhead to be problematic, and the repository ends up entirely self contained for anyone cloning it, which is convenient May 02 19:48:57 I really hate that I always spot certain bugs only *after* I submit the patches to the list for review May 02 19:49:00 so annoying May 02 19:49:36 think i might start sending them directly to myself first, just to review the code one last time in a different context May 02 19:49:55 what would you say is the value added by meta-poky & meta-yocto-bsp? is it the genericx86 machines? May 02 19:50:09 no, meta-yocto/meta-poky is the aforementioned reference distribution May 02 19:50:45 meta-yocto-bsp is its reference bsps largely for testing/demos, afaik. most folks don't use meta-yocto-bsp in my experience, they use the layers from the chip manufacturers May 02 19:50:52 * kergoth shrugs May 02 19:50:58 okay May 02 19:50:59 yup.. maps what I do May 02 19:51:26 would it be suitable to base a new distro on poky? for example inherit the poky distro config? May 02 19:51:26 we replace the meta-poky with our own distribution configuration.. and the bsps, with our own as well.. but we allow people to select meta-yocto/meta-poky if they want that specific distribution config May 02 19:51:30 TI, intel, freescale, xilinx, etc all provide their own BSP layers, and I trust them to support their own hardware well May 02 19:51:38 mago__ yes people do that all the time May 02 19:51:49 kergoth, you have more faith is semi's them I do.. ;) May 02 19:51:51 mago__: you could, yes, or just copy the bits you care about. the goal is poky doesn't add a ton on top of nodistro May 02 19:52:13 fray: heh, well, i trust them with regard to the support of the hardware, less to do the right thing with regard to yocto May 02 19:52:30 some of those layers need more review to make sure they're playing well with others and doing the Right Thing May 02 19:52:38 you still trust them more then I do.. I've not had great hardware/software support from semis.. (any semi) May 02 19:52:59 unless you are buying $ millions in parts, you get 'best effort', often 'worst effort' support.. :P May 02 19:53:26 (board vendors on the otherhand seem to be a little better -- but they still have the "don't have a clue as to how to do the right thing w/in the yocto project/OE environment) May 02 19:53:28 heh, that's a fair point. there can be a fair bit of difference between the sdks shipped to customers and those in the open source layers, too May 02 19:53:36 * kergoth nods May 02 19:53:37 yup May 02 19:54:13 it is fairly common to have to, as a distro / integrator, do a bunch of fixups to the ti/intel/etc layers. which is irritating, since there's no clean way for a distro to exert control over the machine without violating our principles May 02 19:54:30 don't want to fork them, and doing machine hacks in the distro conf is ugly.. May 02 19:55:01 at the moment meta-mentor has its setup scripts supporting local.conf fragments per-machine, and does the fixups there for the most part, configuration wise, so it's user-visible and outside the distro itself May 02 19:55:05 not ideal either, though May 02 19:55:39 need to split that off into a meta-mentor-bsp repo with individual layers per-machine/per-bsp one of these days May 02 19:56:22 kergoth: we do it by supplying machine config includes from our distro, which in turn includes bsp-layer configs. in our includes, we can also fix things May 02 19:56:35 would that be a violation of the principles? May 02 19:59:55 it's not ideal, but that's another option to get the job done. ideally distro/machine/image are completely orthogonal axes, crossing those boundaries violates that, but you have to be realistic. May 02 20:00:24 the reason i did it in the scripts was i saw it as more about the mentor embedded linux *product* than the mentor embedded linux *distro* May 02 20:00:28 * kergoth shrugs May 02 20:00:40 as with anything else, there are multiple options, in this case none are really elegant May 02 20:02:02 yeah, i think in a real world product, everything is not orthogonal May 02 20:02:38 it should be, but 1) it's not always possible, and 2) deadlines often lead to questionable quality stuff at times, have to deal with the realities May 02 20:02:48 one hopes that one has time to clean up that crap and submit things upstream after the release, though :) May 02 20:02:57 * kergoth is currently working on the submission backlog at mentor for 2.2 May 02 20:44:40 * kergoth ponders May 03 01:39:19 hmm, is there a way to not inherit something or make a recipe be ignored based on distro features? May 03 01:54:57 Crofton|work: re: inherit, you can use inline python and just return nothing for the don't inherit case. an empty inherit line is ignored May 03 01:55:35 I have some recipes that try to inherirt qt4x11 May 03 01:55:55 and I just want to skip themrather than pull in layer for this case May 03 01:56:03 worst case just mask them out with BBMASK May 03 01:56:10 ah good idea May 03 01:57:30 even easier now that it can be multiple space-separated patterns, can just += May 03 01:58:22 can I put that in distro.conf file? May 03 01:59:35 yep May 03 02:00:25 yeah, i've often put it there when we're locked to a specific version of a layer but it wants things that no longer exist due to updating another onef ro a bugfix, or the like May 03 02:00:30 lots of reasons, usually temporary, thank god May 03 02:08:05 fray is making a case for why OSVs exist :) May 03 02:09:15 however, I think yocto project sort of helps the SOC vendors to do the _right_ thing ? May 03 02:11:42 kergoth: when we talk about SDKs from SOC vendors, are SDKs from OSVs compatible :), from and end customer point of view its same problem - vendor lockdowns May 03 02:13:15 other day someone was making a fair point when they switched to linux from a properiatry RTOS they did not want a Linux OSV, because that was what they were trying to free themselves from by adopting linux May 03 02:16:32 khem: it helps when some percentage of the osv content is public, I think May 03 02:16:45 i.e. meta-mentor, which also includes our bsp-specific fixups/workarounds in meta-mel **** ENDING LOGGING AT Tue May 03 02:59:58 2016