**** BEGIN LOGGING AT Thu Mar 31 02:59:58 2016 **** BEGIN LOGGING AT Thu Mar 31 03:29:41 2016 Mar 31 06:49:04 good morning Mar 31 13:20:48 JaMa: Hello, Ricardo here. Shall I resend opencv: Use pre-downloaded ipp? Mar 31 13:22:19 ribalda: I can update the _append += one when cherry-picking but please resend updated ipp (if there isn't good reason to hack it like you did) Mar 31 13:23:20 JaMa: take a look to the last mail, I explain why. But if you dont like the hack I can redo it Mar 31 13:23:50 ribalda: please redo, ane you need to redo _append += one as well, because you've removed the leading space now :) Mar 31 13:25:02 JaMa: ok ;) Mar 31 13:25:17 JaMa: Thanks Mar 31 13:46:41 JaMa: Could you take a look to this before I send the patch? http://paste.debian.net/423005/ Mar 31 13:50:24 ribalda: this looks unused now IPP_MD5 = "808b791a6eac9ed78d32a7666804320e" Mar 31 13:50:53 JaMa: It needs to be passed to the cmake configurator Mar 31 13:51:07 you can still let configure to unpack it from ${WORKDIR}/party3/ippicv/ippicv_linux_20151201.tgz if you want Mar 31 13:51:15 that part isn't hacky in my eyes Mar 31 13:51:59 JaMa: Then I have to modify a lot of the cmake, and will probably change between versions Mar 31 13:52:33 ? Mar 31 13:52:53 I was asking only to replace fetch from raw.githubusercontent.com with git clone Mar 31 13:53:08 isn't the rest the same for both ways to download ippicv_linux_20151201.tgz? Mar 31 13:53:52 JaMa: I dont think that I understand you. If the SRC_URI is a tgz, bitbake by default uncompress it Mar 31 13:54:10 but now it is a repo, with some .tgz, therefore it does not uncompress it Mar 31 13:54:14 ah I see Mar 31 13:54:17 so I have to do it manually Mar 31 13:54:25 I thought it was the configure which did the unpack Mar 31 13:54:35 fine then Mar 31 13:54:45 I could probably hack it, but it will be version dependent Mar 31 13:55:04 Because this mimics better what is done by the configure script, there Mar 31 13:55:07 are less things to download, and the unpack of the .tgz is Mar 31 13:55:10 automagically done Mar 31 13:55:15 ^ this confused me ^ :) Mar 31 13:55:40 I thought the automagic is in configure script not bitbake unpacking the .tgz Mar 31 13:55:50 My bad, long working hours. My english degrades by the minute Mar 31 13:55:52 :P Mar 31 13:56:08 same here, don't worry Mar 31 13:56:17 thanks for resolving all my comments Mar 31 13:57:09 JaMa: Thank you. So you want the new version that has a do_unpack_extra(), or you prefer the version that I send previously (v4) Mar 31 13:57:12 ? Mar 31 13:57:52 do_unpack_extra Mar 31 13:58:45 okidoki. Do I need to add something to DEPENDS in oder to use tar, or it is allways assumed to be there? Mar 31 13:58:46 maybe test if you can re-execute do_unpack twice in the same dir Mar 31 13:58:55 i.e. bitbake -c unpack -f opencv Mar 31 13:59:38 in theory you should, but there will definitely be tar-native/gzip-native dependency somewhere in dependency chain of opencv Mar 31 13:59:42 so I wouldn't care Mar 31 14:00:40 JaMa: I managed to reproduce the efivar failures you had, hopefully I can send out new patches tomorrow before leaving for ELC Mar 31 14:01:12 koen: cool, thanks and sorry for insisting on fixing them before merging it Mar 31 14:01:23 no need to say sorry Mar 31 14:01:34 it is supposed to build before going in Mar 31 14:01:59 I know what some issues I report are hard to reproduce, but if it fails only for me then all motivation to get it fixed by submitter will be lost after I merge the inital version :) Mar 31 14:02:06 s/what/that/g Mar 31 14:04:35 JaMa: What is easier for you: That I resend the whole series or just the two patches? Mar 31 14:07:58 just the 2 is fine in this case Mar 31 14:12:03 JaMa: Thanks Mar 31 15:33:57 so I have been trying to figure out this bitbake and yocto for a while. Mar 31 15:34:14 I have a somewhat better understanding of the process Mar 31 15:34:53 but I am really confused as to what I am doing. I made changes to a kernel config with make menuconfig Mar 31 15:35:05 I see the changes being written to a .config file Mar 31 15:35:29 but when I build an image, the changes are not in the resultant image Mar 31 15:59:32 Hi! Can anybody help me with a working xmlrpc-c recipe? I'm trying to build rtorrent with rpc support. Mar 31 16:00:38 i would if I could, but I'm learning yocto/oe at the moment. Mar 31 16:00:49 do you know anything about oe at this point? Mar 31 16:05:26 I've tried a couple of things, including an attempt to revive http://cgit.openembedded.org/openembedded/tree/recipes/xmlrpc-c?h=master Mar 31 16:07:26 one sec i'm looking at your url Mar 31 16:08:28 But it fails with the error unrecognized command line option '--should-not-have-used-/usr/bin/xml2-config' and the only relevant google result was 'stop using xml2-config'... Mar 31 16:08:31 so i'm new to this as well, but that looks like a recipe for building xml library Mar 31 16:09:14 hmm. well I've been doing this and it helps some. Mar 31 16:09:31 bitbake recipename -c shell Mar 31 16:09:47 in your case it might be: bitbake xmlrpc-c -c shell Mar 31 16:09:54 auke-: you'll have to patch it to stop using xml2-config, as it says Mar 31 16:10:04 make it use pkg-config instead Mar 31 16:10:08 if it fails, it will says what the closes name is and you can run it. Mar 31 16:10:11 well there you go Mar 31 16:10:43 kergoth knows what to do Mar 31 16:12:24 kergoth: okay... will try to figure out how to do that Mar 31 16:12:32 thanks Mar 31 17:03:06 kergoth I can do bitbake linux-stream800 -c devshell Mar 31 17:03:16 and do make menuconfig and make Mar 31 17:04:03 but when I exit and do bitbake yocto-nsdk-ip-image-sfu it will build an image which does have the same kernel config Mar 31 17:05:03 i looked through of the files and it appears that this kernel is the one used in the final image. Mar 31 17:06:12 that doesn't surprise me at all, bitbake doesn't track individual files in teh source tree, i thas no idea you changed anything Mar 31 17:06:23 which is why we have the menuconfig task, which handles that for you Mar 31 17:06:29 hmm. Mar 31 17:06:40 i did the -c menuconfig as well Mar 31 17:06:41 don't use devshell to run menuconfig, use the menuconfig task Mar 31 17:07:14 oone sec i'm looking for the exact syntax i used Mar 31 17:08:15 MACHINE=anuvaaz nice bitbake -c menuconfig linux-stream800 Mar 31 17:08:30 i shorted that by setting an env variable for MACHINE Mar 31 17:08:44 and then just do bitbake -c menuconfig linux-stream800 Mar 31 17:19:47 is there a way I can verify that linux-stream800 is the kernel used in nthe actual image recipe besides grepping for config files? Cause that is how I found this earlier. Mar 31 17:21:37 bitbake -e virtual/kernel | grep '^FILE=' Mar 31 17:22:10 that'll tell you what recipe is used as the kernel given your current configuration. it won't tell you what was installed in the image, the info in buildhistory will do that, or the license manifest for the image Mar 31 17:25:44 kergoth: many thanks. i'll note that. fwiw, virtual/kernel is string I found in the machin/anuvaaz.conf file Mar 31 17:25:55 yes, it is Mar 31 17:26:08 i was having to do find and xargs. I'm adding your method to my notes. Mar 31 17:30:50 find isn't going to tell you what bitbake is doing. the only way to know which recipe was used for a given provider is to ask bitbake Mar 31 17:34:14 roger that. Mar 31 17:34:47 your method is the way to do it. i was using what I thought would eventually find it. your way is much better Mar 31 17:36:46 i'd like to see more inspection tools, eventually Mar 31 17:37:16 sigh, i really don't know why this does not work. Mar 31 17:37:30 i'll make a pastebin with my process Mar 31 18:04:53 kergoth: if you could take a look at this please, I would much appreciate it. Mar 31 18:04:57 https://gist.github.com/netskink/24cea0c49a8f71692ac6b02cd52b0c95 Mar 31 18:19:40 otavio: ping. Question on meta-browser && FF-esr Mar 31 18:21:22 We've got a conflicting issue between FF ESR && firefox-l10n & their paths. Then the whole firefox-38.6 or firefox kerfuffle Mar 31 18:21:32 Just want to get an opintion in that Mar 31 18:31:56 WarheadsSE: sure; what is the problem? Mar 31 18:32:18 WarheadsSE: it seems there is a new ESR going to be released (or just released) Mar 31 18:32:26 WarheadsSE: are you going to upgrade it? Mar 31 18:32:27 So: w/ ESR, its starts installing to usr/lib/firefox-MAJ.MIN/ Mar 31 18:32:55 problem then is that we're installing to two paths, hence the waffling on the install paths for the default prefs Mar 31 18:33:26 IMO, we should be making use of a patch to remove the ESR's MAJ.MIN addition from Install in the makefiles Mar 31 18:33:36 so we just get /usr/lib/firefox Mar 31 18:34:05 since firefox-addon && firefox-l10n assume that is where they should be installin extentions to Mar 31 18:34:43 The next failure after that, is that those two actually install to firefox/extensions and not firefox/browser/extentions, and not applying at all Mar 31 18:35:27 so the language packs build, and install, but because they are not in the right place (firefox-38.6/browser/extensions/) they wind up entirely worthless Mar 31 18:36:17 fixing the paths for those, we need to either have them figure out the version of FF ESR (bad), or fix ESR to not install to -MAJ.MIN, so that the other packages are valid out of the gate, other than installing into the wrong subdir Mar 31 18:36:50 Either way, we end up slightly stepping on upstream's ESR makefile, or stepping allll over everything else Mar 31 18:38:30 DIT has said patches, but since they're not just us, we want to check-in on your thoughts before I go slobbering PR's all over the place Mar 31 18:42:40 though I can definitely upgrade the ESR when it comes Mar 31 18:42:44 otavio: * Mar 31 18:47:16 Sorry about the wall Mar 31 19:23:48 WarheadsSE: I agree; patching is better indeed Mar 31 19:24:20 I'll get on PR ing soon Mar 31 19:34:50 Hum, looks like 38.7.1 exists actually Mar 31 19:42:38 ohai, even a 45.0.1esr set, apparently. Mar 31 20:11:54 halstead: bluelightning: not sure where to report this.. so trying here.. i added meta-qcom in the layer index some time ago, but it looks wrong when I look at it in the web page, none of the recipes/machines are listed? what could i have done wrong? Mar 31 20:12:27 ndec: hmm... I remember approving it pretty soon after you sent it, it should have been indexed Mar 31 20:12:35 let me see if there are error logs Mar 31 20:13:00 it's partially there.. the link to README is ok, but no data.. Mar 31 20:14:51 the link to README isn't dependent on fetching the recipe data Mar 31 20:25:00 hmm, do do I install kernel in /boot Mar 31 20:25:04 for once in my life Mar 31 20:26:07 ndec: no mention in the logs, that's very strange... there's something else funny with another layer as well; I've emailed halstead to see if he has any ideas, if not hopefully he can give me access to debug it Mar 31 20:26:16 sorry about the hassle Mar 31 20:26:57 it's ok.. there is no hurry.. but it will be good to understand. one thing I did probably differently is that I used http:// address, not git:// for the git tree Mar 31 20:27:04 not sure if that makes a difference Mar 31 20:33:40 yeah I noticed that as well... shouldn't be an issue, we're just passing that along to git Mar 31 21:17:19 Anyone have immediate insight on this? ERROR: QA Issue: non debug package contains .debug directory: firefox path /work/i586-oe-linux/firefox/38.6.1esr-r2/packages-split/firefox/usr/lib/firefox/components/.debug/libmozgnome.s Mar 31 21:18:15 Seems somehow 3 subdirs w/ .debug didn't get pulled into the debug automatically. Mar 31 21:54:21 WarheadsSE: which version are you using? with earlier versions it was based solely on path so you'd need to extend FILES_${PN}-dbg; recently we made it just pick up any .debug directory Mar 31 21:54:35 bluelightning: I gots it, someone removed the -dbg globs. Mar 31 21:54:46 ah ok, that would do it Mar 31 21:55:03 _recently_ means it doesn't build on anything but master Mar 31 21:55:17 so it might have worked for this author, but breaks for anyone without at least that commit @ master Mar 31 21:55:41 which means it blew up all over the place on my *cough* cora Mar 31 21:56:01 soon.. soon we move to jethro Mar 31 21:56:11 one last point revision though.... Mar 31 21:58:31 Did that for staticdev too ? Mar 31 21:58:32 right yes, that change hasn't hit a stable release Mar 31 21:58:46 er, no, just .debug Mar 31 21:59:05 mm, this person did that too. Got checked just now with a whole bunch of statics in dbg Mar 31 23:21:14 otavio: thar you go. I can work on updating to 38.7.1 or 45.0.1 next week. **** ENDING LOGGING AT Fri Apr 01 02:59:58 2016