**** BEGIN LOGGING AT Tue Jan 06 02:59:59 2015 Jan 06 07:03:19 hi guys Jan 06 07:04:33 do you know of any open-source friendly file share like a github for git? Jan 06 09:35:16 morning all Jan 06 10:02:13 Can yocto varibale be used in C source file? Jan 06 10:06:52 ramose: as long as you pass it as a define, for instance. Jan 06 10:07:18 but not sure if it is a good idea to make a C source file Yocto specific. Jan 06 10:49:36 ramose: idiom is to pass the variable as a define in CPPFLAGS Jan 06 10:53:28 lpaapp,rburton:Thanks for your replies ,I would want to use "SOC_FAMILY" of machine conf file in C source code as define Jan 06 10:53:48 How should I go about it? Jan 06 10:54:05 set a define in CPPFLAGS Jan 06 10:54:15 CFLAGS (since it is C) Jan 06 10:54:26 CPPFLAGS for defines Jan 06 10:54:45 you're thinking of CXXFLAGS which is for c++ Jan 06 10:57:47 rburton: as far as I understand CPPFLAGS is for both, and that is recommended when you have multiple codebase types (not just C). Jan 06 10:57:49 rburton,lpaap: On basis this is flag I wanted to by pass a fucntion call in C code,so CPPFLAGS would be a good idea? Jan 06 10:58:14 ramose: well, it is personal taste, both CFLAGS and CPPFLAGS would work for you. Jan 06 10:58:58 lpapp: http://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Preset-Output-Variables.html can be considered canonical Jan 06 11:01:29 I personally prefer the make documentation here as that is agnostic of the makefile generator, https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html Jan 06 11:02:46 but both will work in the end of the day, so pick whichever you fancy ^_^ Jan 06 11:04:26 lpapp,Thanks ,would be great if you can guide me to some example :) ,I would try to grep this variable in C source meanwhile. Jan 06 11:05:11 ramose: you interestingly use the comma :) Jan 06 11:07:43 ramose: e.g. make CFLAGS=$CFLAGS:${SOC_FAMILY} or something like that would be my guess. Jan 06 11:08:01 and of course your buildsystem needs to respect C(PP)FLAGS Jan 06 11:08:17 wait, no Jan 06 11:08:33 ramose: e.g. make CFLAGS="$CFLAGS -D${SOC_FAMILY}" or something like that would be my guess. Jan 06 11:08:42 I do not know the exact syntax... someone else may know... Jan 06 11:09:32 lpapp,ok and then I can use #define CFLAGS in C source,right? Jan 06 11:10:02 the libxt recipe has this: 'CFLAGS=-D_GNU_SOURCE -I${STAGING_INCDIR_NATIVE} ${BUILD_CFLAGS}' Jan 06 11:10:39 ramose: you can use #ifdef value-of-soc-family ... #endif, yeah. Jan 06 11:11:27 but I am still uncertain whether it makes sense to detect the soc family based on Yocto's variable. Jan 06 11:11:55 lpaap:Thank you,it should be enough for me to get going :) Jan 06 11:12:23 (hopefully not in the wrong direction) Jan 06 11:13:59 lpapp:are you alluding to use something else to determine the soc family,I'm looking forward to it ? Jan 06 11:14:40 usually there are platform defines; is this an exception? Jan 06 11:15:40 lapp: But I would looking into some application code. Jan 06 11:18:15 ramose: not sure what exactly you mean, but it is not a big issue either way. Jan 06 11:18:42 go with what you feel comfortable with :) Jan 06 11:19:35 lpapp: ok,I would try with both the approaches ,Thanks. Jan 06 11:50:13 zeddii_afk: Got something? Jan 06 13:21:56 hmm, I have this in my .bb recipe, but the package is not created: FILES_${PN}-foo = "${FOOBINDIR}" I install every related files into this dedicated FOOBINDIR. Any clue how I could pin it down and/or fix it? Jan 06 13:34:34 lpapp: are the files being picked up by another package, perhaps because that package is before your ${PN}-foo in PACKAGES? Jan 06 13:36:43 bluelightning: hmm, FILES_${PN}-foo does not appear to be in PACKAGES. Now, that is quite odd. Jan 06 13:37:03 you mean ${PN}-foo right? Jan 06 13:38:06 yeah Jan 06 13:42:39 bluelightning: what could cause that? Jan 06 13:43:19 lpapp: when you add a new package, you need to actually add it to PACKAGES Jan 06 13:43:32 FILES isn't enough Jan 06 13:51:40 bluelightning: oh, I missed that since it is just wrapping a huge recipe. Jan 06 13:51:43 and was not extending the huge recipe, thanks. Jan 06 14:01:00 bluelightning: PACKAGE_BEFORE_PN? Jan 06 14:01:30 lpapp: you can use that if you wish yes Jan 06 14:01:53 bluelightning: well, I am lost as no package of ours sets PACKAGES, only that which is tangentially related. Jan 06 14:02:08 e.g. FILES_${PN} is not mentioned explicitly in a "PACKAGES" variable. Jan 06 14:02:27 ${PN} is Jan 06 14:02:29 then there is also USERADD_PACKAGES. It is a bit of jungle. Jan 06 14:02:50 JaMa: not in our recipe, yet it is generated. Jan 06 14:02:54 it may be default, I would not know. Jan 06 14:03:14 yes it's default, bitbake -e knows Jan 06 14:05:23 ah, ok, so the default is ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}, thanks. Jan 06 14:37:11 hmm, I am getting this for a prebuilt binary which was meant to be built outside Yocto, WARNING: QA Issue: No GNU_HASH in the elf binary: Jan 06 14:37:23 can I build it outside Yocto the way that Yocto will not complain? Jan 06 14:37:39 (i.e. not making the warning quite in Yocto as a workaround) Jan 06 14:37:39 quiet* Jan 06 14:39:10 lpapp: add INSANE_SKIP_ += "ldflags" within the recipe Jan 06 14:39:30 lpapp: as per bitbake.conf, -Wl,—hash-style=gnu Jan 06 14:39:47 or that, yes Jan 06 14:39:53 you may find this useful: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-errors-and-warnings Jan 06 14:40:42 yeah, I am aware of how to make warnings quiet. Jan 06 14:40:42 I guess I need to read upon the advantages of -hash-style=gnu Jan 06 14:40:42 thanks. Jan 06 14:41:32 ah sorry I missed your supplementary comment about not quietening the warning Jan 06 14:43:41 https://blogs.oracle.com/ali/entry/gnu_hash_elf_sections Jan 06 14:43:54 seems it performs better than the sysv style hash. Jan 06 15:04:12 bluelightning: INSANE_SKIP_${PN} += already-stripped cannot be further fine-tuned on a file basis rather than package, yeah? Jan 06 15:24:31 lpapp: correct Jan 06 15:27:19 rburton: thanks. Jan 06 15:27:37 so I need to put them into separate packages for nwo. Jan 06 15:27:37 now* Jan 06 15:28:20 (or just override the warnings for everything) Jan 06 15:35:17 rburton, bluelightning: INSANE_SKIP_${PN}-foo += "already-stripped" did not help. I still get the warnings. :( Jan 06 15:35:35 I just said bitbake foo, that ought to eliminate the warnings, yeah? Jan 06 15:36:24 yeah Jan 06 15:37:28 then I am not sure why it is not working as it is supposed to... How can I further pin that down? Jan 06 15:39:06 this is what I have, PACKAGE_BEFORE_PN_append = " ${PN}-foo" and INSANE_SKIP_${PN}-foo += "already-stripped" Jan 06 15:50:27 ldflags supressed the gnu-hash warnings, though, I wonder why already-stripped, not then. I do not seem to have made a typo Jan 06 15:50:32 so if one works, why not the other ... Jan 06 15:52:25 are the files witn warning really packaged in ${PN}-foo? (I would check packages-split/bar-foo) Jan 06 15:56:57 JaMa: yes Jan 06 16:08:21 why does Yocto try to generate .debug for binaries without debug symbols? Jan 06 16:09:18 lpapp: because it ensures we get an error when this is not possible and can act accordingly. If this is expected you can 'disable' it in the recipe. Jan 06 16:11:05 I know that one can disable debug symbols, but I am not sure I follow the "error logic". Jan 06 16:11:15 what error are you referring to? Jan 06 16:11:32 lpapp: if we expect to have debug symbols we need to try to split them to know this fails or not. Jan 06 16:11:37 i think he's pointing out that we don't want to silently ignore already stripped binaries, but want to be notified when such is the case, so as to fix buildsystems that strip at build time, for example Jan 06 16:11:38 the system detects a lack of debug symbols and issues a warning or error.. Jan 06 16:12:01 kergoth: thanks for helping with the English skills :) Jan 06 16:12:02 kergoth: yeah, that is a warning, not error. Jan 06 16:12:12 that is why I am confused what error is being referred to. Jan 06 16:12:21 lpapp: if it is not an error for you, you can skip the split. Jan 06 16:12:51 and that could come without .debug established when it is not possible. Jan 06 16:12:52 lpapp: so error out forces people to ack on it Jan 06 16:12:56 lpapp: no, whether its an error or a warning is user controllable. see ERROR_QA and WARN_QA in insane.bbclass Jan 06 16:13:08 its a distro decision generally Jan 06 16:13:21 kergoth: no, I am referring to the default state, but I am still unsure how it is related to .debug Jan 06 16:13:39 it would be possible to detect already stripped binaries without create .debug when it is not possible. Jan 06 16:13:53 without creating*. I do not see the connection to .debug for that. Jan 06 16:14:35 what I am trying to express is that my question is not about the already stripped error/warning, however it is configured Jan 06 16:14:58 my question is when we already could get that warning/error, why is there still an attempt to create .debug when it is not possible? It seems meaningless to me. Jan 06 16:15:27 lpapp: this is easy. Make your distro and change the default policy. Jan 06 16:15:58 I do not (yet) see how it is distro specific. I see it meaningless all the time for now. Jan 06 16:16:14 What is the point of creating .debug if it is not possible? That seems to be an ultimate question to me distro agnostic. Jan 06 16:17:05 Already stripped? Yes -> issue warning/error + do not generate .debug instead of: Already stripped? Yes -> issue warning/error + generate .debug. Jan 06 16:19:50 (Btw, I am not asking this for a rhetorical or theoretical reason, but because I see my build failing due to this. Why I could circumvent the issue around with further settings on top of INSANE settings, it would seem more logical to me that the INSANE settings would resolve this, too) Jan 06 16:20:10 While* Jan 06 16:21:31 the error _on top of the insane already-stripped error_ is: ERROR: QA Issue: non debug package contains .debug directory: Jan 06 16:21:52 so I will need to settings, whereas it would be nice if I say yocto, well, it is already stripped, do not introduce further problems with trying to generate .debug. Jan 06 16:22:04 two settings* Jan 06 16:23:14 so basically what I am trying to debate, why do I need to tell Yocto not to generate debug symbols when I say yocto, hey, it is already stripped. It seems like double coding the same factor to me. Jan 06 16:23:32 (unless I am missing something) Jan 06 16:24:39 lpapp: why are you getting .debug/ directories if the binaries are already stripped? Is there a mix of stripped and unstripped binaries? Jan 06 16:25:30 there is a simple switch to completely disable the strip/split process.. (it's the split process that generates the .debug) Jan 06 16:26:05 lpapp: there's no 'one solution fits all' so it is indeed a distro setting Jan 06 16:26:27 fray: ok, so in that case I would not get the already stripped complains either, I assume? Jan 06 16:26:32 INSANE_SKIP_... already-stripped skips the QA Jan 06 16:27:00 if 'already-stripped' in (d.getVar('INSANE_SKIP_' + pn, True) or "").split(): Jan 06 16:27:00 bb.note("Skipping file %s from %s for already-stripped QA test" % (file[len(dvar):], pn)) Jan 06 16:27:00 if (d.getVar('INHIBIT_PACKAGE_DEBUG_SPLIT', True) != '1'): Jan 06 16:27:00 that prevents the splitting Jan 06 16:27:12 ok, I see, so the main problem is that already-stripped still does not work for me. Jan 06 16:27:15 rburton: good question, no... Jan 06 16:27:27 or maybe yes :) Jan 06 16:27:28 then the file has debug symbols in it.. just not a full set.. Jan 06 16:27:50 I believe I really need two packages as it cannot be fine tuned on a file basis ... Jan 06 16:28:00 even though the packages will not make any sense separately. Jan 06 16:28:16 and I do not wish to disable debug for all in that one package either. Jan 06 16:28:28 so there is no optimal solution as far as I can see, unless I am missing something ... Jan 06 16:28:29 correct, it's designed to be package and recipe specific.. Jan 06 16:28:36 the splitting recipe specific.. and QA package specific Jan 06 16:28:37 yeah, that is my concern. Jan 06 16:28:44 it does not satisfy my use case. Jan 06 16:30:52 is there a way runtime not to allow a single package installation, only if both are being installed? Jan 06 16:32:06 rdepends? Jan 06 16:32:25 more importantly: what next can I do to see why already-stripped does not work? packages-split shows that the files are in the package for which I am setting the already-stripped argument. Jan 06 16:33:01 is that option supposed to work for "mixed" packages? Jan 06 16:33:13 (that is the only idea that comes to my mind to check) Jan 06 16:34:35 my guess is a simply typo somewhere.. start by inspecting bitbake -e for INSANE_SPLIT_ --- where package is the package the files are going into.. (not the -dbg) Jan 06 16:34:44 that should contain the magic already-stripped item Jan 06 16:36:20 that would be INSANE_SKIP Jan 06 16:39:33 sorry yes Jan 06 16:46:14 speaking of typos :p Jan 06 16:49:28 RP: found other issue in recent changes in kernel handling Jan 06 16:49:50 RP: base now has 'clean' for mismatching configure stamps right? Jan 06 16:50:07 RP: but it runs: 'make clean' and don't take KERNEL_SRC into account Jan 06 16:51:43 rburton: you mean circular RDEPENDS? Jan 06 16:55:04 yeah Jan 06 17:48:34 hi Jan 06 17:48:52 I have integrated meta-efl layer in yocto Jan 06 17:49:21 while running enligtenment I am setting F1(recover ) error while running first time on arm Jan 06 17:49:32 Can anyone help ne out with this? Jan 06 18:43:07 how is the FILES_${PN}-etc pattern matched in case of "ambiguity"? What is the ordering? The order that they appear in PACKAGES and PACKAGE_BEFORE_PN? Jan 06 18:45:52 order in PACKAGES (PACKAGE_BEFORE_PN is part of that) Jan 06 18:46:34 ok, so I can put the specific files in there into a package before a more generic "catch-more" package. Jan 06 18:46:43 say, /opt/foo in pkg1 and the /opt (to catch the rest) in pkg2. Jan 06 18:54:44 JaMa: thanks. Jan 06 18:55:40 fray: bitbake -e recipe | grep INSANE_SKIP -> looks as expected Jan 06 18:56:21 INSANE_SKIP_mypackage="already-stripped ldflags" Jan 06 18:56:53 still I get this: WARNING: File '/opt/foo' from myrecipe was already stripped, this will prevent future debugging! Jan 06 18:57:22 fwiw, I am using dylan if that makes a difference for already-stripped? Jan 06 18:59:34 zeddii, why isn't there an error if you have a file listed as a patch in the .scc file, but the patch isn't in the SRC line? Jan 06 19:00:01 is there a way in the FILES_ specific to exclude a path rather than include? Jan 06 19:00:01 because they don't have to be in the SRC_URI :) Jan 06 19:00:03 specification* Jan 06 19:00:36 well, if I put it in th escc file, but the file isn't there it isn't applied and the re is no message I am an idiot Jan 06 19:00:56 I require frequennt reminders I am an idiot Jan 06 19:01:00 it should freak out. this is on master ? I wonder if I broke something .. Jan 06 19:01:08 Crofton|work, as do I :) Jan 06 19:01:08 it is likely master Jan 06 19:01:28 ok. let me poke at it. I take your comment as a bug report .. since that isn't good. Jan 06 19:01:29 work had the scc file with the patch line, but no patch in work Jan 06 19:02:11 * zeddii needs to build karma for the conferences this year :P Jan 06 19:02:48 Crofton|work. if the .scc propagates, the code should propagate any patches that are listed in it recursively. it's a feature of how it works outside the build system .. but if it isn't found, it should exit 1 and break the build. Jan 06 19:06:33 is there any log that shows the patches being applied? Jan 06 19:07:35 hmm. the verbosity is down by default, to just a spinner in do_patch Jan 06 19:08:49 I'm already in that code for another feature. I'll double check. Jan 06 19:09:46 * zeddii waits for a kernel to fetch Jan 06 19:10:44 something stupid is going on Jan 06 19:13:57 not patching and not updating .config Jan 06 19:14:01 hmm, Jan 06 19:14:20 hrpm. Jan 06 19:14:32 2015 is shaping up to be exciting at the start. Jan 06 19:14:39 * zeddii is playing bug whack a mole. Jan 06 19:24:18 zeddii, I may have been given a bogus patch Jan 06 19:35:27 zeddii, the patch I have should fail to apply Jan 06 19:35:32 not seeing that either Jan 06 19:35:51 hrmph. Jan 06 19:38:35 I can't say the problem isn't at my end, but the recipe builds, just no kconfig option and no patch in source tree Jan 06 19:38:39 and no erros Jan 06 19:43:38 hmm. I suppose this is all internal. if there's something you can point me that, that would help. or give me an idea how to mock it up. Jan 06 19:47:15 well, uncommited changes to something that is public now Jan 06 19:52:12 something really weird is going on Jan 06 19:52:21 I lose an entire source direcotry on the kernel tree Jan 06 19:53:33 you may be running afoul of the kernel build changes. we have some build issues that we are working through. those are the bugs I'm whack-a-moling Jan 06 19:55:04 why would drivers/input/misc disappear on me? Jan 06 19:56:08 * Crofton|work flips the table Jan 06 19:58:10 Crofton|work. was this on a clean, straight up build. or were you rebuilding ? after a sstate clean ? out of tree modules ? Jan 06 19:58:39 I did a cleansstate Jan 06 20:00:20 could be what we are hunting then. we are missing files like version.h :) Jan 06 20:00:27 rofl Jan 06 20:00:42 I found an older build that makes the same kernel version Jan 06 20:00:48 and it has the directory Jan 06 20:00:57 so I think I can say it used to work Jan 06 20:01:36 OK, so I am blaming you Jan 06 20:02:27 * zeddii is partially just the guy stuck on the hamster wheel. Jan 06 20:12:13 I suppose this is the week everything that got broke over the holiday is fixed Jan 06 20:15:32 Crofton|work: indeed. and such fun! Jan 06 20:15:38 yep Jan 06 20:17:45 the annoying thing is the complete lack of debugging messages Jan 06 20:45:27 Tizen is Yocto enabled! Jan 06 20:45:28 https://fosdem.org/2015/schedule/event/deviot03/ Jan 06 20:46:03 zeddii, if you have anything that needs testing, please send it my way Jan 06 20:46:56 will do. I'm working on three issues at the same time .. so I'm swapping and thrashing a bit. Jan 06 21:13:11 * zeddii throws up his hands for a bit, and heads for supper. back later. Jan 06 21:24:40 gah, why do the python license classifiers not include version numbers for half of them? Jan 06 23:03:51 otavio: you were asking for patches for the kernel issue to test? Jan 06 23:04:04 RP: yes Jan 06 23:04:14 I had several cases to test :) Jan 06 23:04:51 otavio: try dan.rpsys.net/fsl.patch Jan 06 23:05:02 zeddii: ^^^ Jan 06 23:05:51 otavio: assuming I have the right issue... Jan 06 23:06:15 RP: this is for the Qt issue Jan 06 23:06:24 otavio: yes Jan 06 23:06:27 but what about the linux/version.h issue? Jan 06 23:06:37 zeddii: were looking at it I think Jan 06 23:06:41 otavio: I'm not familiar with that one :/ Jan 06 23:06:47 otavio: bug number? Jan 06 23:07:22 RP: I don't think it has been reported in bugzilla Jan 06 23:07:30 RP: I was dicussing with zeddii it today Jan 06 23:07:41 otavio: ok, well I know nothing of it then Jan 06 23:08:13 RP: anyway, back to the Qt issue. One thing which concerns me is why DEPENDS on virtual/kernel is not enough to guarantee do_install completion Jan 06 23:08:58 otavio: we're making the kernel bypass sstate. It is just as efficient to directly extract the source as it is to unpack an sstate tarball Jan 06 23:09:10 otavio: the downside is we need to be more clear about the dependencies Jan 06 23:09:36 RP: I'd assume it would guarantee that sysroot were populated before it 'green' the dependency Jan 06 23:09:55 otavio: we're bypassing sstate in this case Jan 06 23:10:10 its pointless to extract the kernel, copy it around, then tar it up again for sstate Jan 06 23:10:17 RP: Are you confident the price is worth it? Jan 06 23:10:34 RP: tar it again? Jan 06 23:10:39 you mean for the source? Jan 06 23:10:43 yes Jan 06 23:10:54 otavio: Its a departure from the way we've worked, I do think it will give better user experience in the end Jan 06 23:11:05 RP: but the sysroot shouldn't be lost. Jan 06 23:11:29 I did try and explain all this in the original patches Jan 06 23:12:00 RP: if this is the case, we could have an annonymous python which check for virtual/kernel and adds do_install splicit one? Jan 06 23:12:43 otavio: I doubt you need this in general Jan 06 23:12:54 e.g. if you just RRECOMMEND some kernel modules Jan 06 23:13:08 if you depend on the kernel sources, you do need it Jan 06 23:13:29 this was why we created the kernelsrc bbclass iirc Jan 06 23:13:32 RP: that's why I said it for depends Jan 06 23:14:01 otavio: you can put virtual/kernel in DEPENDS for a module dependency for example Jan 06 23:14:08 it means multiple things Jan 06 23:14:24 otavio: I would have suggested kernelsrc.bbclass except for the fact you're doing machine specific overrides Jan 06 23:14:47 machine overrides with variable flags is harder Jan 06 23:15:01 RP, I'm also having "weird" kernel build issues Jan 06 23:15:24 RP: I am afraid we are going to make it way too complex Jan 06 23:15:32 I'mm all angry, will calm down and start over in the morning Jan 06 23:15:41 RP: I am not sure it is worth it Jan 06 23:16:04 I'd ask that people file clear bug reports Jan 06 23:16:20 "mentioing it on irc" isn't doing any favours here Jan 06 23:16:45 yeah, I was talking to zedii trying to figure out what was ahppening Jan 06 23:16:57 no visibale errors, but wrong things happening Jan 06 23:17:02 RP: calm down. It is not easy to understand it all. Jan 06 23:17:08 basically, hard to amke a good bug report Jan 06 23:17:15 RP: so we need to understand to provide a good bug report Jan 06 23:17:27 +1 Jan 06 23:17:32 RP: so be thankful instead of complaining on us here Jan 06 23:17:41 well, equally, I've been asked today by two peope how they can help Jan 06 23:17:47 +1 Jan 06 23:17:54 and I can't tell them "go read 48 hours of irc logs" Jan 06 23:18:13 RP: good and today I used full day looking at it Jan 06 23:18:13 well, it would help if they were here to talk with us and zedii Jan 06 23:18:21 he went to eat, which is fine by me Jan 06 23:18:47 Crofton|work: can you try and write down what you do know in a bug, please? Jan 06 23:18:58 if I could explain what is happening without seeming nuts I would make a bug Jan 06 23:19:14 RP: and I don't think I qualify as a begginer in YP so I am afraid we need to improve how it will integrate or it will be too hard for people to get it right. Jan 06 23:19:33 I'm going to calm down and touch base with zedii in the morning Jan 06 23:19:42 otavio: I do agree on that. To do that we need to figure out where the problems are Jan 06 23:19:52 The problems appear complex and we don't understand them yet Jan 06 23:19:57 * Crofton|work isn't that wound up, but he has got a work task blocked by this because I am an idiot **** BEGIN LOGGING AT Tue Jan 06 23:21:19 2015 Jan 06 23:21:43 RP: http://ci.ossystems.com.br/job/fsl-community-bsp-master/425/consoleFull#-1374903367df9aaadc-264d-4163-ae95-fd7844a10b4f Jan 06 23:22:12 RP: imx-test is one triggering the linux/version.h issue Jan 06 23:23:01 the weird thing I see is a patch not applying Jan 06 23:23:08 and kernel source directories vanishing Jan 06 23:23:29 but my plan is regroup and start over in the morning Jan 06 23:24:25 RP: your Qt patch makes sense. But I think it is complex to people to graps it Jan 06 23:25:59 otavio: so we should just revert the changes? Jan 06 23:27:04 RP: To be honest I don't know. But I do think it is way difficult for people to understand it. Even worse as kernel will be a completely different creature ... Basically DEPENDS works for all, but kernel. Jan 06 23:27:47 RP: so I am really thinking it is not worth the price. Most of time kernel is not rebuild that ofthen so optimizing for this might be overkill at this price. Jan 06 23:28:08 otavio: there are a number of problems these changes are trying to solve, not just that "optimisation" Jan 06 23:28:25 RP: one possibility is the annonymous alternative I suggested; it makes DEPENDS to work Jan 06 23:28:30 RP: which? Jan 06 23:28:47 RP: with this kernel changes? Jan 06 23:28:49 otavio: the ones I wrote about in the several emails I sent out on this topic Jan 06 23:29:16 RP: be more specific, please or point me the bug # Jan 06 23:29:18 making things like on target sources for kernel modules complete Jan 06 23:29:36 making things like module building against the kernel source work properly rather than missing files Jan 06 23:29:37 RP: ok but this is a new thing. Jan 06 23:29:49 otavio: it isn't new Jan 06 23:30:00 RP: agreed. Valid. But the kernel sstate drop is not related. Jan 06 23:30:09 otavio: yes, it really is Jan 06 23:32:59 part of the problem here is we've tried to keep compatibility in some senses and not require people to change things. That massively complicated things and we perhaps shouldn't have done that Jan 06 23:32:59 RP: How come? I couldn't think any related reason but less time packing/unpacking stuff Jan 06 23:33:43 otavio: if we "fixed" the various module building properly, it would have created a serious drop in performance which people would not like Jan 06 23:33:44 RP: well maybe adding a new field makes it less complicated Jan 06 23:34:10 RP: like KERNELSRC_DEPENDS = "1" Jan 06 23:34:16 or whatever Jan 06 23:35:10 All the black magic with explicit task dependencies when I have a virtual/kernel in depends field makes no sense at all for someone reading the recipe Jan 06 23:35:35 otavio: I do agree and we probably need some kind of class Jan 06 23:36:04 otavio: at this point we probably do need to take a look at the several different kernel classes we have and try and figure out if we can have a better set of classes though Jan 06 23:36:20 Agreed. Jan 06 23:36:31 RP: Are you with fsl-arm built? Jan 06 23:36:47 RP: try imx-test. It will trigger the version.h failure Jan 06 23:36:49 module, module-base, linux-kernel-base, kernel, kernelsrc, kernel-module-split and so on is just crazy :( Jan 06 23:37:08 otavio: I can see the problem even without building it Jan 06 23:38:12 otavio: I think what I might propose is moving the kernel source dir out of sysroots and into work-shared or something Jan 06 23:38:35 as well as moving the binary build dir somewhere separate to the source for all cases Jan 06 23:38:45 otavio: I need to talk with zeddii about this Jan 06 23:39:16 he's probably watching hockey :) Jan 06 23:39:29 right, I mean tomorrow Jan 06 23:39:36 Right Jan 06 23:39:42 I am making a Canadian joke Jan 06 23:39:49 RP: how the work-shared would help ? Jan 06 23:39:56 Crofton|work: lost on me Jan 06 23:40:10 otavio: its clear sstate covers sysroots, it doesn't cover work-shared Jan 06 23:40:19 Canadians are hockey mad Jan 06 23:40:25 RP: right Jan 06 23:40:31 wmat's son was on TV watching a juniors game Jan 06 23:40:49 RP: but how would it help with depends madness? Jan 06 23:41:21 otavio: it doesn't, it helps with your complaint about people being confused Jan 06 23:41:38 otavio: I suspect there are several things we need to do to improve things, not one magic bullet Jan 06 23:42:42 RP: I see Jan 06 23:44:41 RP: how we could 'use' kernelsrc for conditionals, as the qt4 bbappend case. Any idea? Jan 06 23:44:59 otavio: for your specific issue, I'm wondering about dan.rpsys.net/fsl2.patch Jan 06 23:45:32 Might help; let me try. Jan 06 23:46:09 otavio: I'm fairly sure that will fix your issue, I'm more worried about any others it may create :) Jan 06 23:46:23 RP: heheh let me check it Jan 06 23:49:52 /home/otavio/src/ossystems/yocto/build/tmp/work/imx53qsb-oel-linux-gnueabi/imx-test/1_3.10.31-1.1.0-r0/imx-test-3.10.31-1.1.0-beta/module_test/mxc_sdma_mem_test.c Jan 06 23:49:55 | /home/otavio/src/ossystems/yocto/build/tmp/work/imx53qsb-oel-linux-gnueabi/imx-test/1_3.10.31-1.1.0-r0/imx-test-3.10.31-1.1.0-beta/module_test/mxc_sdma_mem_test.c:21:27: fatal error: linux/version.h: No such file or directory Jan 06 23:49:59 | #include Jan 06 23:50:01 | ^ Jan 06 23:50:03 | compilation terminated. Jan 06 23:50:06 RP: didn't solve it. Jan 06 23:53:34 otavio: ok, working on it Jan 06 23:54:06 RP: It is intriguing as linux/version.h is in sysroot Jan 06 23:54:27 ~/src/ossystems/yocto/build/tmp/sysroots/imx53qsb/usr/include/linux/version.h Jan 06 23:55:46 otavio: I notice that STAGING_DIR_KERNEL isn't in INCLUDE_DIR ? Jan 06 23:56:02 STAGING_KERNEL_DIR even Jan 06 23:56:19 RP: but ~/src/ossystems/yocto/build/tmp/sysroots/imx53qsb/usr/include/linux/version.h this is STAGING_INCDIR Jan 07 00:00:02 otavio: not here it isn't :/ Jan 07 00:00:50 otavio: version.h is a build artefact, it goes into the kernel build output directory Jan 07 00:01:31 RP: even if you do: bitbake linux-imx; than bitbake imx-test Jan 07 00:01:35 RP: it keeps failing Jan 07 00:02:50 otavio: I know what is wrong, working on a patch Jan 07 00:04:28 otavio: I updated fsl2.patch Jan 07 00:04:41 otavio: its more a proof of concept about what is wrong but it does fix the build Jan 07 00:06:42 otavio: the other option is to add include/linux/version.h to the make command in do_make_scripts() Jan 07 00:07:05 RP: testing Jan 07 00:08:02 RP: works Jan 07 00:08:07 RP: fsl2 works Jan 07 01:31:25 hi guys Jan 07 01:32:16 how does 'fakeroot' work in Yocto recipes? and what's its range? If I have fakeroot a() that calls b(), will b be embraced? Jan 07 01:41:52 fakeroot is replaced by pseudo Jan 07 01:42:08 I do not know much past that Jan 07 01:45:08 Xz: anything that forks from the parent fakeroot/pseudo environment will be within the same fakeroot environment Jan 07 01:50:02 hi nrossi Jan 07 01:50:17 Crofton: hi :) Jan 07 01:51:09 what time is it there? Jan 07 01:51:18 I need to work out my calibration Jan 07 01:51:42 Crofton: its just before lunch :), 11:50am Jan 07 01:51:57 2051 here Jan 07 01:52:25 SoylentYellow, nrossi does meta-xilinx work **** ENDING LOGGING AT Wed Jan 07 02:59:58 2015