**** BEGIN LOGGING AT Wed Nov 14 03:00:00 2012 Nov 14 07:14:01 gm Nov 14 07:56:30 Hello everybody. I wrote some recipes but now I am getting an error when I try to install my package (ERROR: QA Issue: libubus rdepends on libubox-dev), so I added RDEPENDS = "libubox-dev" in libubus_1.0.bb and I added also in libubox_1.0.bb this => PROVIDES = "libubox-dev" FILES_libubox-dev = "${libdir}" FILES_libubox-dev = "${includedir}".... Am I missing something ? Nov 14 08:00:17 In fact when I do that, I get more error and new packages ?? ERROR: QA Issue: libubus-doc rdepends on libubox-dev ERROR: QA Issue: libubus-locale rdepends on libubox-dev Nov 14 08:17:06 hi, does anyone else get this error ? "arm-angstrom-linux-gnueabi-objcopy: Unable to recognise the format of the input file" Nov 14 08:17:32 what could I be doing wrong? Nov 14 08:51:12 I wonder from where libubus-doc package comes from (http://pastebin.com/dia3B0R0 Nov 14 08:56:54 anarsoul: ping Nov 14 09:03:58 good morning Nov 14 09:34:53 hello mckoan Nov 14 09:43:10 I think there is a bug somewhere... Things get worse.. Now I just want to compile a package which is called libuci, bb => http://pastebin.com/d2NBrb7W, error => http://pastebin.com/a1Cs6QFJ Nov 14 09:47:23 vadmeste: you don't need the PROVIDES statement and for RDEPENDS you need to suffix it with an override for the specific package name Nov 14 09:47:43 i.e. which package specifically should depend on libuci-dev ? Nov 14 09:48:13 bluelightning: that's the problem, it tells me "ERROR: QA Issue: libuci rdepends on libuci-dev" Nov 14 09:48:18 actually, why is that even needed? Nov 14 09:48:51 I really don't know... Nov 14 09:49:00 I think you'll find it's not Nov 14 09:49:28 what problem were you trying to solve by adding it? Nov 14 09:49:43 bluelightning: this one "ERROR: QA Issue: libuci rdepends on libuci-dev" Nov 14 09:49:59 that is caused by the RDEPENDS statement Nov 14 09:50:07 I mean why did you add the RDEPENDS statement in the first place? Nov 14 09:50:35 I already understood your question.. Let's paste my initial bb and its error Nov 14 09:50:58 oh wait... I see the problem Nov 14 09:51:22 FILES_libuci-dev="${libdir}" is the cause and probably not even needed Nov 14 09:51:47 can you wait a little ? I will paste my initial bb Nov 14 09:52:12 sure Nov 14 09:52:53 bb : http://pastebin.com/a1Cs6QFJ Nov 14 09:52:59 error : http://pastebin.com/rhV9LzQu Nov 14 09:53:33 ah, the bb link isn't the right one Nov 14 09:54:38 umm.. I am sorry, still newbie in OE, what does that mean ? Nov 14 09:55:32 I mean, when I click on the link you just pasted above for "bb" I see the pasted error output, I presume it was meant to be the original recipe...? Nov 14 09:56:08 bluelightning: ohh.. I understand... sorry http://pastebin.com/x7URCyRT Nov 14 09:56:42 but the error link is correct Nov 14 09:57:30 so it can only be that files are being picked up by libuci-dev that are depended upon by files in libuci Nov 14 09:58:23 this is unusual, but would have to be some kind of path issue during do_install Nov 14 09:58:36 I would suggest looking in packages-split to see which files are in the libuci-dev package Nov 14 09:59:18 I mean packages-split in the workdir for the libuci recipe; if you're not sure where that is you can run: bitbake -e libuci | grep ^WORKDIR Nov 14 10:00:36 bluelightning: in my last bb, I still don't have libuci-dev package.. let me check with you please, to add libuci-dev package it is enough to add PROVIDES = "libuci-dev" FILES_libuci-dev = "${libdir}", right ? Nov 14 10:00:48 no, you should not add those Nov 14 10:00:55 the -dev package is automatically set up Nov 14 10:01:01 see meta/conf/bitbake.conf Nov 14 10:01:48 the only time you should need to touch the definitions for the -dev package is if there are files that are needed for development that are not being picked up which you need to add Nov 14 10:03:05 in any case, PROVIDES is for satisfying build-time dependencies, not runtime ones - the latter is RPROVIDES; and if something already in PACKAGES (as libuci-dev is here) then it's already effectively in RPROVIDES Nov 14 10:04:54 okay, I looked in libuci-1.0-r0/packages-split/libuci-dev/usr/lib and I can find libuci.so Nov 14 10:04:57 eh Nov 14 10:05:01 i just wondered Nov 14 10:05:06 if there is a telnetd in openembedded Nov 14 10:05:23 i researching security holes Nov 14 10:07:43 Vutral: I think we might only have busybox telnet in modern OE-Core / layers Nov 14 10:11:37 bluelightning: when i add a patch for busybox what do you think until it propagated to projects which base on openembedded ? Nov 14 10:12:06 vadmeste: ok, I guess that this particular piece of software is not versioning it's shared library Nov 14 10:12:16 bluelightning: i request a primitive host_access style validation for blank root login Nov 14 10:12:37 bluelightning: i can add it myself but i got no commit access to openembedded.... Nov 14 10:12:54 Vutral: I'm not sure but it sounds like something you should talk to upstream about Nov 14 10:13:20 we don't enable busybox telnetd out of the box, FWIW Nov 14 10:13:51 sure but its probably your codebase they merge/fork from Nov 14 10:14:22 vadmeste: which is probably not right... all libraries should really be versioned Nov 14 10:14:42 Vutral: by upstream I mean busybox Nov 14 10:17:01 vadmeste: you can work around it if you really have to by setting FILES_libuci and FILES_libuci-dev so that the .so file goes into FILES_libuci instead; but I would advise fixing the versioning Nov 14 10:20:23 guys, I somehow got stuck and need some help please... I have a recipe that does a PACKAGES += "${PN}-python" for a package with some extra python bindings, then I have another package that needs this "${PN}-python" as a runtime dependency, but when in this second package I do RDEPENDS_${PN} = "package1-python" bitbake tells me "nothing RPROVIDES package1-python" Nov 14 10:20:26 what am I missing? Nov 14 10:21:26 bluelightning: I think that I will rebuild all from the beginning, I am pretty sure that I succesffully built it yesterday Nov 14 10:21:49 vadmeste: sure, but I wouldn't think this problem will go away by itself Nov 14 10:22:13 Jin^eLD: check the final value of PACKAGES for the first recipe using bitbake -e recipename | grep ^PACKAGES Nov 14 10:22:20 Jin^eLD: maybe it isn't what you think it is..? Nov 14 10:22:45 bluelightning: ok Nov 14 10:22:57 bluelightning: well I took the name of the ipk that was generated for that python package.. but let me check what you suggested Nov 14 10:23:06 vadmeste: FYI, SRCREV = "HEAD" is not correct, if you always want the latest version you need to use SRCREV = "${AUTOREV}" Nov 14 10:23:22 thanks :) Nov 14 10:24:22 bluelightning: but you indeed were right Nov 14 10:24:33 the ipk has some "-v2-" in it while the PACKAGES string does not Nov 14 10:25:07 thank you Nov 14 10:26:06 Jin^eLD: well, RDEPENDS / PACKAGES / etc. don't always match up with the names of the actual package files (ipk/rpm/deb) - e.g. debian renaming Nov 14 10:26:39 I guess I was not fully aware of that :) Nov 14 10:28:18 FYI, you can translate between the two by looking in tmp/pkgdata/* if you need to Nov 14 10:28:43 (after the packages are built) Nov 14 10:30:04 oh, ok, good to know, but actually I should have tought about -e because that one I knew already Nov 14 10:41:10 well, I deleted the work dir and now bitbake libuci succeed Nov 14 10:44:02 by the way, I have another package which is called libubox and I renamed it to ubox and now when I do bitbake freecwmp I get ERROR: QA Issue: freecwmp rdepends on libubox-dev ERROR: QA Issue: freecwmp rdepends on ubox-dev Nov 14 10:44:28 I think that I should delete all build directory :D Nov 14 11:07:58 vadmeste: sounds like something strange is going on there :( Nov 14 11:08:30 is the other recipe also using cmake? Nov 14 11:11:23 yes.. anyone I found INSANE_SKIP.. I will try to install all in my images and checks if it will work Nov 14 11:11:47 I know I am a newbie and need more time to learn Nov 14 11:12:41 INSANE_SKIP is definitely not the way to handle this... Nov 14 11:12:49 I know Nov 14 11:12:56 something is genuinely broken, particularly if it's not happening every time Nov 14 11:22:57 Hi, I'm trying to use oe from an automated build system. Is there a way I can have a single shell command which sources oe-init-build-env and calls bitbake? Nov 14 11:25:09 trj, can you not just create a shell script that does that? Nov 14 11:28:53 Ah, yes. A script with ". oe-init-build-env dir; bitbake blah" just works. I feel silly now, but thanks. Nov 14 14:02:15 hey. i've been working on a recipe similar to update-rc.d, and i'm puzzled on how come the same update_rc.d recipes is used both to cover the target package and the native package; even though mine is similar only the native package is build, and i get an error about the ARM one Nov 14 14:02:29 so... how does the trick work? Nov 14 14:04:42 can anybody enlighten me what exactly makes bitbake go to the same recipe? Nov 14 14:14:13 BBCLASSEXTEND Nov 14 14:15:51 pb_, thanks Nov 14 14:16:15 it does work when building explicitly, but the rdepends does not find the non-native recipe Nov 14 14:19:57 CMoH: there isn't really any concept of a runtime for native though since there's no packaging... Nov 14 14:20:36 hmm... can you check if i understand correctly: Nov 14 14:23:13 i have update-rc.d.bb that produces update-rc.d-native (which is used for initscript recipes to preinstall symlinks in /etc/rcX) and update-rc.d (which does the same thing on the target machine when opkg installs some pacakge from the update feeds) Nov 14 14:23:48 now, recipes with initscripts inherit update-rc.d.bbclass, which adds a DEPEND on update-rc.d-native, and a RDEPENDS to update-rc.d Nov 14 14:24:56 now, i've replicated the system for my recipes, except bitbake does not properly build the non-native version of the recipe Nov 14 14:27:29 but i don't understand how does the recipe switches from being an x86_64 targeted to an arm targeted depending on where it's being pulled from Nov 14 14:29:57 CMoH: native.bbclass does most of the actual work Nov 14 14:33:46 CMoH: the RDEPENDS on update-rc.d ought to ensure that update-rc.d gets built for the target *if* you are building a target recipe Nov 14 14:34:07 otherwise the RDEPENDS will do nothing, but for a native recipe I'm not sure why you would want it to... Nov 14 14:39:03 well, update-rc.d.bb gets to act as update-rc.d-native when it's DEPENDed and as update-rc.d (not native) when RDEPENDed Nov 14 14:39:26 hence my misunderstanding Nov 14 14:39:38 on how that works behind the hoods Nov 14 14:40:02 (i should refrain from writing american expressions which i don't know if i know how to spell...) Nov 14 14:40:21 it's alright, I know what you're talking about :) Nov 14 14:45:27 well, i'll guess i'll create two recipes and see how that works Nov 14 14:47:55 BBCLASSEXTEND basically says "give me another target that inherits the specified class" Nov 14 14:48:16 a target for the same recipe, I mean Nov 14 20:06:45 hi Nov 14 20:07:55 were mails to oe-commits sent 3 times? Nov 14 20:09:06 I just happen to see same commits to pulse and xorg, Nov 14 20:10:50 anyone has an example how to create a recipes for a few binary only apps? Nov 14 20:11:26 BTW I'm beginning ot think the construction of the SDK (using rpm packages) isn't working right.. my logs have a bunch of messages about 'alternatives' not running properly.. Nov 14 20:11:33 I'm going to investigate a bit further in a few Nov 14 20:27:30 hmmmm Nov 14 20:49:37 I received from a third party developer a huge binary tarball where everything need to be installed in /usr/local and when I try to write a recipe for it the work directory is empty, any idea on how to fix this? Nov 14 20:50:47 chouimat: have you tried installing the files manually to required directory, in that case /usr/local ? Nov 14 20:51:06 I guess you need to override or append do_install method Nov 14 20:51:58 eren: I will try that. I had to fight for 2 weeks for them to give the tarball install of the install shell script ... Nov 14 20:52:47 you need to do install like: install -m 0644 ${WORKDIR}/some-file ${D}/usr/local/ Nov 14 20:53:44 which will just install files from WORKDIR to destination Nov 14 20:53:55 thanks Nov 14 20:54:10 chouimat: btw, you said that work directory is empty, is it successfully extracted btw? Nov 14 20:54:25 the work directory should not be empty if the tarball has been successfully extracted Nov 14 20:54:36 the destination directory would be empty in that case Nov 14 20:55:07 eren: doesn't look like it extracted correctly ... Nov 14 20:56:29 chouimat: how does your recipe look like? Nov 14 20:56:42 it would be useful to paste your recipe to pastebin and give the link Nov 14 20:59:51 eren: http://pastebin.com/k0csFghd Nov 14 21:31:47 chouimat: I'm sorry that I need to go. Btw, there is unnecessary slash in: install -m 0644 ... Nov 14 21:32:08 it should be ${D}usr/local/bin Nov 14 21:32:26 if I'm not mistaken, of course :) Nov 14 21:32:33 hey. I love .bbappend. It makes it very easy to enable/disable features in packages that already have recipes. Can I do the same thing with .inc files? Nov 14 21:32:42 eren: ok thanks Nov 14 21:33:32 that is, will bitbake recognize .incappend files in a high-priority layer, and use it to modify corresponding .inc files in lower-priority layers? Nov 14 21:35:06 nstiurca: no, there is no such mechanism Nov 14 21:35:27 nstiurca: the workaround would be to bbappend all of the recipes that use the inc Nov 14 21:35:55 bummer Nov 14 21:36:31 sounds very brittle Nov 14 21:37:29 on a seemingly unrelated note, has anyone here tried enabling OpenMP support for ARMv7-a targets? Nov 14 21:38:16 I see it's enabled only for powerpc/powerpc64 in the gcc 4.6 and up recipes. Nov 14 22:26:45 ooo success!! looks like OpenMP works on ARMV7-a! all I had to do was add 'RUNTIMETARGET_append_armv7a = " libgomp"' to recipes-devtools/gcc/gcc-configure-runtime.inc, then make sure I can find omp.h, and off I go!!! **** ENDING LOGGING AT Thu Nov 15 02:59:58 2012