**** BEGIN LOGGING AT Wed Apr 17 02:59:59 2013 Apr 17 04:09:23 is there any effort under way to make make bitbake compatible with python 3.X? Apr 17 07:04:00 good morning Apr 17 07:38:37 Good morning Apr 17 07:38:50 Hi mckoan Apr 17 08:07:50 morning all Apr 17 08:09:38 morning all (UGT) Apr 17 08:10:57 hi silviof, apelete, all Apr 17 08:13:46 morning silviof, silvio__, apelete, mckoan, all Apr 17 08:13:48 l) Apr 17 08:13:49 :) Apr 17 08:16:10 :) Apr 17 08:20:22 hi silvio__, silviof, bluelightning Apr 17 08:21:47 hi apelete, bluelightning, mckoan , silviof , all Apr 17 08:30:20 I have still some trouble with my sdk during launching of the "xmlrpc-c-config", it tells to linker use the wrong path for library: i686 instead of arm, some suggest ? Apr 17 08:42:03 bluelightning: morning, did you see my Hiawatha patch I posted yesterday, I tagged it meta-oe rather than meta-webserver by mistake; I just want to make sure it wasn't missed in all the current hustle and bustle! Apr 17 08:44:19 jackmitchell: yep saw that, should be able to merge it today, thanks Apr 17 08:50:03 hi all Apr 17 08:50:14 i have a doubt in rootfs generation.. :!! Apr 17 08:50:56 in my rootfs so many other bin files and .so files arecoming.. which i don't need in my final rootfs Apr 17 08:51:01 how to controle them Apr 17 08:53:21 Sj: 99% of files in the rootfs come from packages Apr 17 08:54:18 Sj: there are several ways packages get into your image - directly in IMAGE_INSTALL; via IMAGE_FEATURES; or indirectly via dependencies of other packages that are explicitly installed by the former two Apr 17 08:54:20 i have two folders i686-linux and x86_64 i need the files only form i686-linx folder.. in that my modules i'm builind.. Apr 17 08:54:49 IMAGE_INSTALL what is that?? Apr 17 08:55:01 Sj: the x86_64-linux directory is for native tools, these won't end up in your image Apr 17 08:55:16 yeah.. Apr 17 08:55:19 Sj: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#usingpoky-extend-customimage Apr 17 08:55:32 oh then from where i'm getting extra binaries.. Apr 17 08:55:49 I'd generally recommend the Yocto Project manuals (development manual and reference manual especially) Apr 17 08:56:00 Sj: which extra binaries especially? Apr 17 08:56:11 s/especially/specifically/ Apr 17 08:56:17 ohh link was good. i wil go through it Apr 17 09:00:34 Sj: images end in deploy/images Apr 17 09:01:15 Sj: after build is done you need to look into deploy/ dir for results (packages, images, kernels) Apr 17 09:03:18 hi Apr 17 09:08:07 i have a "execvp: /bin/sh: Argument list too long" error in kernel do_install. any suggestions ? ( except of removing some modules ) Apr 17 09:08:52 remove all modules :) Apr 17 09:09:36 pwgen: OE-Core commit 1e63a3b7b7915d40bb59976a02b9f53968997ed3 is supposed to resolve that Apr 17 09:11:05 although if you have your own linux-libc-headers recipe (if so, you probably shouldn't) then you'll need to apply the fix to that yoursel Apr 17 09:11:07 f Apr 17 09:16:39 thx i will try it Apr 17 09:20:07 hi all Apr 17 09:25:32 bluelightning: ahh, its my raspberry 3.8.y recipe . and i have to patch it myself .. Apr 17 09:25:48 Since yesterday I have been getting this error: net-snmp-server-snmpd-systemd does not appear in package list, please add it Apr 17 09:26:39 I added it to my IMAGE_INSTALL but the error still persists... any ideas what caused this? Apr 17 09:29:33 jackmitchell: I suspect it's talking about SYSTEMD_PACKAGES, but you'd have to git grep for that error to be sure of where it's coming from Apr 17 09:30:57 bluelightning: ah yes, systemd.bbclass Apr 17 10:48:03 bluelightning: paul, I just rebased and sent a v2 of the snmp patch; could you try applying again, see if your applying problems are fixed? Apr 17 10:48:31 jackmitchell: will do as soon as it arrives, thanks Apr 17 10:50:39 jackmitchell: wrong list I'm afraid... Apr 17 10:50:48 I can try it anyway before you resend though Apr 17 10:51:12 bluelightning: ah, blast Apr 17 10:53:32 jackmitchell: still fails... I tried applying it with patch, and it reports: Apr 17 10:53:34 Hunk #1 FAILED at 1. File meta-oe/recipes-extended/net-snmp/files/sync-with-5.7-branch.patch is not empty after patch, as expected Apr 17 11:01:30 jackmitchell: I wonder if something is mangling the email; it might be easier to push a branch somewhere Apr 17 12:00:13 bluelightning: I'm having a compile error on uicmoc package (http://paste.debian.net/250064/), and I would like to know how uicmoc was pulled into the build. how can I do that ? Apr 17 12:00:35 I'm looking into bitbake -g but don't know how to use it yet Apr 17 12:00:51 or even if that's what I want Apr 17 12:01:29 apelete: grep uicmoc depends.dot after bitbake -g Apr 17 12:10:55 JaMa: you mean after 'bitbake -g uicmoc' ? that's how I actually ran it Apr 17 12:11:54 apelete: bitbake -g whatever-you-were-building-originally ;) Apr 17 12:16:33 crap, there's a hell lot of packages which depend on uicmoc: http://paste.debian.net/250079/ Apr 17 12:16:55 guess I'll have to go the hard way and dig into the compile error then Apr 17 12:17:16 JaMa bluelightning: thanks for helping Apr 17 12:21:40 apelete: within opie, yes... uic / moc are at the heart of Qt Apr 17 12:22:13 uic is what converts UI definition files into C++ source files Apr 17 12:22:33 moc expands the Qt signals/slots system into actual C++ code Apr 17 12:23:47 old Qt2.3. :} Apr 17 12:24:53 right :) Apr 17 12:28:51 thanks for the insight on uicmoc. Apr 17 12:29:06 this is my first build error, previous errors were due to missing dependencies (depency chain errors). let's say it's a progress :) Apr 17 12:29:14 will try to fix it Apr 17 12:29:49 s/depency/dependency/ Apr 17 12:32:43 apelete: hmm, looks like this is a compiler strictness issue... Apr 17 12:32:57 I should really be building this more regularly Apr 17 12:41:33 bluelightning: ha. got an idea on what should be fixed ? Apr 17 12:58:50 apelete: not really, without looking at the code I'm not sure what the error is talking about... Apr 17 12:59:09 I'm at work so I'll have to dig into it later Apr 17 12:59:16 opie is just a side-project for me... Apr 17 13:08:14 bluelightning: no problem. will let you know if I find something Apr 17 13:53:28 Hello everybody. I think that udev-182 doesn't work properly (or doesn't work at all).. I can't find any udevd process running... Anyone confirm ? Apr 17 15:57:09 vadmeste: which MACHINE are you using? Apr 17 15:57:32 someone can tell me where find info about difference between "sdk" "native" "nativesdk" in the BBCLASSEXTEND, and how have to use these parameters Apr 17 15:58:17 mckoan: raspberry pi Apr 17 15:58:18 the BBCLASSEXTEND is a way to make a single recipe that will work for target, "native" and "nativesdk" Apr 17 15:58:26 otherwise you'd need to write three recipes Apr 17 15:58:36 mckoan: Well, it seems that the init script is mistaken Apr 17 15:58:58 I don't think 'sdk' is value.. but native (runs on the host, during the build process) and 'nativesdk' (built to run on a generic host, as part of the SDK) are supported Apr 17 15:59:07 because the init script search for /lib/udev/udevd or it is found in /sbin/udev/udevd Apr 17 15:59:08 'sdk' is a supported value... Apr 17 15:59:43 fray, but i m not clear where use foo-native and foo-nativesdk, which are the difference? Apr 17 16:00:24 any -native package runs withint he bitbake/oe-core system to provide something that the host system may not have, during cross compilation Apr 17 16:00:55 -nativesdk are 'cross' built for a generic SDK host. They are exported as part of the populate sdk process, and made available for use OUTSIDE of the bitbake/oe-core build system Apr 17 16:01:01 vadmeste: interesting, unfortunately I don't have experience with raspberry Apr 17 16:01:17 The -native use the host's compiler and libc.. the -nativesdk are 'cross' built.. and use a custom gcc and glibc Apr 17 16:01:38 vadmeste: and I wonder that anybody noticed this as a problem before Apr 17 16:03:10 mckoan: this udev patches were blindly applied without testing them... having an @intel.com address seems to be enough to get commited every crap into oe :( Apr 17 16:03:26 mckoan: maybe because they are using systemd instead of the classic init system Apr 17 16:03:43 vadmeste: I would suggest to post such question to oe mailing list Apr 17 16:04:00 ensc|w: LOL Apr 17 16:04:40 ensc|w: there are a lot of issues to deal with right at the end of the cycle, it's not nearly as simple as that Apr 17 16:05:08 the systemd stuff is nontrivial to begin with, lots of combinations of things to test Apr 17 16:05:19 bluelightning: yes; commiting something which breaks usespace apis is really the right thing to do at the end of a cycle... Apr 17 16:06:03 breaking multilib support and other existing isn't useful either.. the changes are an attempt to get things working again for all users Apr 17 16:06:21 right, there are multiple considerations Apr 17 16:06:33 mckoan: I already found a patch in the mailing list which correts the issue.. it seems that it's not applied Apr 17 16:06:48 ensc|w: you'll notice that that change is about to be mostly been reverted by one of RP's patches just posted Apr 17 16:06:57 the autobuilder/autotest system was designed to test many of these combinations, but it obviously didn't test that one Apr 17 16:07:00 vadmeste: feel free to modify the recipe and send a patch Apr 17 16:11:00 fray: from reading history of this change, it seems that only one script of one package was affected. Now, udev rules and keymaps are at random locations (which are different for udev and systemd-udev) where no 3rd part project expects them. Nothing in the system will detect that rules at /lib/udev/rules.d are ignored; only the user will see that the device does not work as expected Apr 17 16:12:09 I understand that.. AFAIK, it's being worked on.. Apr 17 16:14:16 fray, so I m not clear which and where put recipes for a correct build of my sdk, for example I had 3 main files for my sdk: a meta-toolchain.bb that call the task-sdk-host-nativesdk.bb and a toolchain-target.bb Apr 17 16:15:28 the BBCLASSEXTEND is not needed in the task-sdk-host-nativesdk (the package is nativesdk specific and already is named right) Apr 17 16:15:33 I dunno about the toolchain-target.bb Apr 17 16:15:33 fray, so I put the foo-nativesdk in the task-sdk-host-nativesdk.bb, and foo-dev in the task-target.bb Apr 17 16:15:59 that looks right on the surface Apr 17 16:16:40 fray, I put the BBCLASSEXTEND = "native bativesdk" only in the recipe foo.bb Apr 17 16:17:03 that looks fine as well Apr 17 16:17:52 fray, it looks fine also to me but it does not work in my case... Apr 17 16:17:59 moin Apr 17 16:18:19 what is the error? Apr 17 16:18:23 fray, I nee foo-native somewhere? Apr 17 16:18:28 fray, I need foo-native somewhere? Apr 17 16:19:31 fray, I had a Qt progams that use "xmlrpc-c" library,but , when I try to compile it in sdk i get an "undefined reference" error Apr 17 16:19:34 no what is the exact error you are getting Apr 17 16:20:03 that is a recipe problem then.. your foo.bb appears to be missing something required in the SDK.. Apr 17 16:20:06 fray, /usr/local/oecore-i686/sysroots/i686-angstromsdk-linux/usr/libexec/armv7a-vfp-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/4.7.1/ld: error: cannot find -lxmlrpc++ Apr 17 16:20:16 fray, release/backend.o:backend.cpp:function Model::Backend::ParseDate(xmlrpc_c::value const&): error: undefined reference to 'xmlrpc_c::value::cValue() const' Apr 17 16:20:33 your image, or target configuration is missing whatever provides xmlrpc++ (library) Apr 17 16:20:46 fray, I had installed library, and it works in "normal" building, but does not link in sdk Apr 17 16:21:16 add that to your IMAGE_INSTALL, or add it to yoru recipe as a RDEPENDS.. or add it to the TOOLCHAIN_TARGET_TASK Apr 17 16:21:39 if it works in the normal system, then you have something that happens to have built earlier.. but is missing fromt he dependency set Apr 17 16:23:13 fray, I added in RDEPENDS in this way : xmlrpc-c-nativesdk, if u want i pastebin it Apr 17 16:23:58 http://paste.ubuntu.com/5716371/ Apr 17 16:24:44 http://paste.ubuntu.com/5716375/ Apr 17 16:25:09 http://paste.ubuntu.com/5716376/ Apr 17 16:25:52 your SDK recipe may need some things added to it Apr 17 16:26:05 the defaults: Apr 17 16:26:13 TOOLCHAIN_HOST_TASK ?= "task-sdk-host-nativesdk task-cross-canadian-${@' task-cross-canadian-'.join(all_multilib_tune_values(d, 'TRANSLATED_TARGET_ARCH').$ Apr 17 16:26:19 TOOLCHAIN_TARGET_TASK ?= "task-core-standalone-sdk-target task-core-standalone-sdk-target-dbg" Apr 17 16:26:41 (see meta/classes/populate_sdk_base.bbclass) Apr 17 16:27:42 ya the other recipes look fine.. you just need to figureout whatever provides that missing thing and put it in the target package section Apr 17 16:32:51 fray, could be something related to curl-config Apr 17 16:34:04 fray, I found finally this stuff: https://github.com/ensc/xmlrpc-c/blob/master/doc/INSTALL particular at lines 169-181, but I have no idea how to solve it Apr 17 16:36:42 none has trouble like this during sdk creation? Apr 17 16:38:16 silvio__: 'error: cannot find -lxmlrpc++' means, there is no libxmlrpc++.so; you should check whether this file exists resp. whether it was built with xmlrpc-c (maybe, the c++ parts was disabled) Apr 17 16:40:01 ensc, I use the only recipe of xmlrpc-c that works, that I took from OE-Classic, and adapted to OE-core Apr 17 16:41:24 it not seams that c+++ is disabled: http://paste.ubuntu.com/5716424/ Apr 17 16:53:59 silvio__: you might need the staticdev package; the c++ libraries are .a files only Apr 17 16:55:48 thanks all, i have to go Apr 17 16:55:51 afk Apr 17 18:35:38 What's 567 in the following line? Apr 17 18:35:40 File "__anon_567__home_mario_src_ossystems_products_platform_sources_poky_meta_classes_base_bbclass", line 162, in __anon_567__home_mario_src_ossystems_products_platform_sources_poky_meta_classes_base_bbclass Apr 17 18:37:16 mario-goulart: is it the starting line of the anonymous python section? Apr 17 18:37:24 s/section/function/ Apr 17 18:38:22 bluelightning: and 162 the line in that function? Apr 17 18:38:32 mario-goulart: yes Apr 17 18:39:44 bluelightning: is it possible that 567 represents the _last_ line of the anonymous function? On line 567 I have a } which closes a long anonymous pythong function. Apr 17 18:40:26 mario-goulart: it could be, I have to admit I have never tried to look up using that number, usually the rest of the output has been sufficient to find the problem in the cases I've dealt with Apr 17 18:40:48 Line 162 of that function has a getVar(SRC_URI, True), and the problem I get is exactly because I'm moving SRC_URI from recipes to a class. Apr 17 18:41:39 mario-goulart: I've heard you mentioning the issue before but I'm afraid I don't have any particular insight on the problem Apr 17 18:42:15 Alright. No problem. Thanks anyway. Apr 17 19:12:09 oe's SDK generation is pretty cool Apr 17 19:12:16 (just putting that out there) Apr 17 19:12:44 remember there are two ways t generate an SDK.. image based or recipe based... :) Apr 17 19:13:22 recipe based would be like "bitbake meta-toolchain-qt", image-based would be...? Apr 17 19:13:37 image based.. bitbake -c populate_sdk core-image-sato Apr 17 19:13:42 <3 image based Apr 17 19:13:49 oh nice Apr 17 19:13:53 that will generate an SDK that contains everything needed to build applications to run on the sato image Apr 17 19:14:05 so it gets its package list from the image recipe Apr 17 19:14:17 yes.. and adds in the -dev components automatically Apr 17 19:14:32 :) Apr 17 19:14:32 * fray wrote that bit.. Apr 17 19:14:44 that is our primary workflow.. the recipe based are secondayr Apr 17 19:15:11 our == company I work for.. Apr 17 19:16:17 hmm in meta-toolchain-qt.inc there is a function "toolchain_create_sdk_env_script_append()" how is that functionality handled with image-based creation? Apr 17 19:16:23 should that function be defined in the image recipe? Apr 17 19:16:31 you could define that in your image.. Apr 17 19:16:56 Hmm, you know what I want to see, and I've wanted it for a long time — been on the long term todo for a while, I want to try doing an OE build entirely from git repositories, no fetching upstream tarballs, no patching. along the lines of what baserock does with its lorry tool Apr 17 19:16:57 * kergoth ponders Apr 17 19:17:13 for our commercial product we have some bbclasses that do that for all images.. then we just inherit it via the local.conf Apr 17 19:17:46 kergoth, I'd say about 80-90% of what is needed it there Apr 17 19:18:01 the hard work is working through them, recipe by recipe, and finding/creating definitive git repos for them Apr 17 19:18:15 converting upstream other scm where necessary, creating tar-based ones manually, .. Apr 17 19:18:16 even that should be able to be automated.. Apr 17 19:18:35 to a certain extent, yeah. depends on how thorough you want to be, too Apr 17 19:18:36 if it starts as an SCM.. branch from the SRCREV and apply patches as commits.. Apr 17 19:18:52 if it doesn't start as an SCM, unpack, init, commit.. patch as commits Apr 17 19:19:18 I've done some of this in the past.. it works pretty nicely.. but I found the SRC_URI approach was better for my needs Apr 17 19:21:14 then do_fetch/do_unpack/do_patch get modified to check for a git instead.. Apr 17 19:24:16 * kergoth nods Apr 17 20:03:49 anyone aware of work being done to create a qtserialport recipe? Apr 17 20:04:11 i didn't see it listed on layers.openembedded.org Apr 17 20:15:19 * waynr will work on it Apr 17 20:52:19 qtserialport has LICENSE.GPL, LICENSE.LGPL, LGPL_EXCEPTION.txt, and LICENSE.FDL Apr 17 20:52:29 which of these shouldI include in LICENSE? Apr 17 20:53:12 waynr: all? Apr 17 20:53:26 okay, space separated? Apr 17 20:55:44 waynr: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-LICENSE Apr 17 20:56:05 ah right, rtfm :) thanks Apr 17 20:56:28 it's easier than me just explaining the same thing :) Apr 17 20:57:06 yeah Apr 17 20:57:06 but if you have questions after reading that then of course I'll be happy to answer them Apr 17 20:57:30 I'm not quite sure what the LGPL_EXCEPTION is going to translate to if anything Apr 17 20:57:40 yeah i was gonna ask about that Apr 17 20:57:53 it would depend on what's in it Apr 17 20:58:26 you can add arbitrary license names to the LICENSE field, there's not a limited set Apr 17 20:59:01 although any names not associatable to files in the common licenses directory won't be represented in the collection of license texts produced at the end Apr 17 20:59:15 basically allows object code that includes material from a header file to be distributed under "terms of your choice" Apr 17 20:59:31 with extra provisions on that provision Apr 17 20:59:53 I guess, consult a lawyer if you want a real answer ;) Apr 17 21:00:02 no modification of the header files, limites on incorporated material, etc etc Apr 17 21:00:04 heh Apr 17 21:12:26 * fray notes he did a talk earlier this year about discovering the 'true' license of a binary.. Apr 17 21:12:59 using the dwarf debug symbols you can figure out what went into the build of a given binary, then correlate that back to the license data (SDPX) for a given recipe.. put that together and you have a true license Apr 17 21:13:15 lawyers still need to review.. but it's a better indicator of conflicting or not.. Apr 17 21:13:32 (note that is all still theoretical at this point... but it's doable) Apr 17 21:35:25 khem: ping Apr 17 21:36:54 JaMa: are you around? Apr 17 21:37:36 bluelightning, khem is at collab Apr 17 21:37:49 Crofton|work: ok, thanks Apr 17 21:40:25 bluelightning: sort of Apr 17 21:41:06 * JaMa returned from kitchen after chopping a lot of onions.. so barelly see IRC :) Apr 17 21:41:28 JaMa: just wondering if you might be able to help test/review whats on http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=master-next Apr 17 21:41:40 JaMa: a *lot* of systemd issues have been found and fixed Apr 17 21:41:50 but time is running very short indeed Apr 17 21:42:09 if not, no problem Apr 17 21:50:33 I'm close to finish fixing meta-qt5 so I would probably continue on that Apr 17 21:50:59 in spare cpu time I'll review and test those changes but cannot spend much time on it Apr 17 21:55:23 and jenkins is 50+ hours behind again, running world-image for all 3 qemus does not work well Apr 17 22:06:31 JaMa: ok, no worries Apr 17 22:18:53 is it possible to "disable" a recipe in case a dependency is not available? Apr 17 22:19:38 the only way I can think of is to add PACKAGES_DYNAMIC to a recipe and define everything in an anonymous python function Apr 17 22:24:12 dv_: one way to do it is using BBMASK Apr 17 22:24:30 that will prevent the recipe from even being parsed Apr 17 22:24:39 but I mean to automate it Apr 17 22:27:54 for example, to add a bsp specific EFL evas engine if the evas recipe is available Apr 17 22:29:27 would that be a separate recipe or a reconfiguration of evas? Apr 17 22:29:41 the latter Apr 17 22:30:02 well I could imagine both, actually. a separate recipe for the engine, a reconfiguration to make it the default one Apr 17 22:31:09 the only way I can think of that isn't hideous is to provide your own evas recipe in the bsp Apr 17 22:31:10 i actually wondered if there is a way to let bitbake ignore a .bbappend file without corresponding .bb one. that would solve this too Apr 17 22:31:43 dv_: you can do that globally, BB_DANGLINGAPPENDS_WARNONLY Apr 17 22:31:58 users of your BSP would also have to set that Apr 17 22:32:17 or, you can tell your users to BBMASK out the parts they can't use Apr 17 22:32:20 meta-ti does that Apr 17 22:32:33 hmm yes. or create an extra layer with the demos. it still is not a perfect solution, because perhaps I only want one of the demos Apr 17 22:32:54 hmm use BBMASK for that, I thought this is an ugly hack Apr 17 22:33:12 I'll try it, thanks Apr 17 22:33:38 could always raise SkipPackage in a recipe to make it unbuildable the same way COMPATIBLE_HOST is implemented, rather than doing it via bbmask Apr 17 22:33:41 depends on your goals Apr 17 22:34:16 well ideally you could build with just oe-core and the bsp layer, and you get bbnotes informing you that these demos require extra layers Apr 17 22:34:40 (if you for example are just building core-image-minimal) Apr 17 22:34:50 and if you actually try to build one demo without the dependencies, it fails Apr 17 22:35:30 akin to a ./configure script that prints which components it will build and which ones it wont Apr 17 22:55:23 * waynr is currently trying to build a toolchain with SDKMACHINE = "i686 x86_64" Apr 17 22:58:58 does that variable accept multiple values? Apr 17 22:59:08 if it does it's the first I knew about it Apr 17 23:00:08 looking at the code I'm almost positive it can't Apr 17 23:08:06 * JaMa agrees Apr 17 23:19:09 well it's building, but probably just creating a bunch of funky-named packages and binaries Apr 17 23:25:13 i did do a grep on SDKMACHINE and thought it didn't look very promising Apr 17 23:37:02 hmm, yep appears to be causing problems Apr 17 23:39:00 we should probably validate the value set in that var Apr 17 23:39:05 * bluelightning adds to todo list **** ENDING LOGGING AT Thu Apr 18 02:59:58 2013