**** BEGIN LOGGING AT Mon Jun 24 02:59:58 2013 Jun 24 08:19:06 morning all Jun 24 08:19:20 moin Jun 24 08:23:22 hi bluelightning Jun 24 08:29:08 hi Net147, RP Jun 24 08:32:21 bluelightning: I have a tip for backport to dylan, but haven't confirmed that it fixes issues we're seeing yet (I'll send backport request in email when I can confirm it) http://git.openembedded.org/openembedded-core/commit/meta/lib/oe/path.py?id=2f954a9a6932f1e6c564e7e7aacaac628a75eed7 Jun 24 08:33:05 from description it seems like it's triggered only in combination with http://git.openembedded.org/openembedded-core/commit/meta/lib/oe/path.py?id=5853e0f482b22258c909268fe71673a29e31989b but some folks have so fast machines that they are seeing the same errors Jun 24 08:34:20 JaMa: yeah I thought those two went together as well Jun 24 08:58:49 bluelightning: this is the error we're seeing http://bpaste.net/show/109267/ Jun 24 08:59:10 bluelightning: if I prepare patch for backport would you prefer to include both or just the later? Jun 24 09:00:22 JaMa: can I get back to you on that? Jun 24 09:02:29 backporting both is easier because both apply cleanly in dylan, I'm runing clean build to confirm that they don't depend on any other changes Jun 24 14:21:34 Anyone here alive/active/knowledgable about bitbake? Jun 24 14:22:32 Stygia: ask, don't ask to ask. Jun 24 14:22:41 Stygia: knowledgeable is a spectrum Jun 24 14:23:19 rburton, Pardon. Has just seen this channel appear somewhat dead, was unsure if it was active or not. Jun 24 14:24:07 In that case, my question is this. I am trying to add a custom recipe to bitbake with yocto, to install a perl script I wrote myself. However, I keep an error that my recipe is "not found in the base feeds". Jun 24 14:24:41 Which seems to indicate it isn't "officially" known, but I don't see why that would be a dependency. Neither me nor my collegue has had luck with trying to install this package into bitbake, although bitbake compiles it seemingly without a hint of error. Jun 24 14:25:39 We have not been able to find anything. Just wondered if someone here could point me to appropriate documentation or help me out. Jun 24 14:26:56 so that error comes from the rpm packager Jun 24 14:27:19 rburton, Quite possible. Jun 24 14:27:36 can you pastebin the recipe? Jun 24 14:27:41 Yes, hang on. Jun 24 14:28:30 This would be it: http://pastebin.com/GmhCGPFW Jun 24 14:29:26 ${D}{bindir} Jun 24 14:29:29 you need another $ in there Jun 24 14:29:47 so you're generating an empty package, an empty packages get disappeared Jun 24 14:29:51 which is why your package doesn't exist Jun 24 14:30:16 rburton, Hmm, that is what made sense to me also ${} looking like a scalar dereferences in perl, but I found this in an example. Jun 24 14:30:27 oh? the example is wrong Jun 24 14:30:30 rburton, I will try, give me a minute, and thank you for the pointer. Jun 24 14:30:31 D and bindir are variables Jun 24 14:31:07 rburton, Alright, I must admit I just resigned myself to it being a multi-dimensional hash, like in perl $hash{slice}{slice} Jun 24 14:31:39 nah, bindir is $prefix/bin by default Jun 24 14:32:13 and D is the staging install location, same as DESTDIR in autotools Jun 24 14:33:00 D = "${WORKDIR}/image", says bitbake.conf Jun 24 14:33:06 bitbake.conf is a goldmine for variables Jun 24 14:39:20 rburton, Thank you for your help so far. Unfortunately, seems like this didn't fix it, we are still getting "install: cannot stats `daemon`; no such file or directory Jun 24 14:39:53 My impression is that, if I have a recipe in the folder movis, I put the bb file in /movis/daemon_1.0.bb, and the actual files itself in /movis/movis/daemon.pl? Jun 24 14:40:04 Uh not /movis but ./movis/, whatever. Jun 24 14:42:10 Stygia: daemon.pl must be referred to in SRC_URI Jun 24 14:42:24 so that it gets fetched Jun 24 14:43:08 ideally the file should be in a "files" or "daemon" subdirectory next to the recipe Jun 24 14:46:22 zenlinux: PM Jun 24 14:46:44 bluelightning, Indeed. Seems like this has done the trick. Thank you for your help. Jun 24 15:03:44 Stygia: no problem :) Jun 24 15:10:51 Does anyone know if there is a default ${COMMON_LICENSE_DIR}? I have a moderately vanilla bitbake setup with yocto. Now, I want to add some recipes for some CPAN module I need, and I need to specify their license file. The examples says to use something like ${COMMON_LICENSE_DIR}/MIT (In this case GPL), which would be handy if possible, since I could then download and checksum the individual license only once. So is there a "default" location i Jun 24 15:10:51 nto which to put these things? Jun 24 15:11:47 I want to download GPL license once, checksum it, place into this directory, and then copy that LICENSE and LIC_FILES_CHKSUM everywhere it's needed. Jun 24 15:13:43 My other solution would be to include a license file with each package and then use that... Jun 24 15:13:58 Stygia: have a look at meta/files/common-licenses/GPL-* Jun 24 15:18:26 Stygia: does the upstream source not include a license file? Jun 24 15:23:30 bluelightning, It includes a README that says "This file is open source", but not a proper license. Jun 24 15:24:12 bluelightning, Eh as long as nobody sues me for making this recipe for some CPAN modules I don't care honestly. I want it to work for me, anyone else who'd need these modules, and for the original author not to get pissy. Jun 24 15:24:25 bluelightning, Seems like we'll just checksum the README file then. Jun 24 15:24:47 morning Jun 24 15:25:11 Stygia: I see... in that case yes, pointing to ${COMMON_LICENSE_DIR}/GPL- is one way of handling it Jun 24 15:25:36 Stygia: you may also at the same time hassle upstream to do the right thing ;) Jun 24 15:25:49 bluelightning, Oh I intend to publish this upstream if I can. Jun 24 15:26:01 bluelightning, I'll put in on my github and add it to recipes.yocto.com (or something) Jun 24 15:26:20 bluelightning, In case you can't tell, I usually don't mess with yocto/bitbake here, I'm a "regular" programmer Jun 24 15:26:29 Stygia: sure, I meant tell the author of the piece of software to include a proper license file Jun 24 15:27:12 ideally every piece of open source software would come with a proper license file; I know not all do unfortunately Jun 24 15:27:53 bluelightning, Ah, right. Hmm yea I suppose I could. He doesn't seem like he cares much about the license, though, but it would make it easier for us. I'll drop him a line. Jun 24 15:29:48 bluelightning, Another question, the docs said that a recipe can contain python or bash code, does this mean I can add "perl MakeFile.PL" to do_install() and it will work just like that? Jun 24 15:30:20 Stygia: yes, since do_install is defined as a shell task Jun 24 15:30:42 or rather, as a shell function Jun 24 15:31:03 bluelightning, Fantastic. Jun 24 15:33:08 bluelightning, Hmm alright. Jun 24 16:50:25 interesting "Poky" has a copy(?) of the oe-build-init script at the roo level Jun 24 16:54:57 evanp: So, I looked at the license manifest for sdk. It does work for core-image-sato-sdk at HEAD. have you looked in tmp/deploy/licenses/-- IIRC it should have worked in 1.2. Jun 24 16:55:00 Crofton|work: oe-core has one there too... Jun 24 16:55:55 I know Jun 24 16:56:06 it need to be there since it has to be stand alone Jun 24 16:56:31 I wa confused by some references on the list, so spent some time tryin gto figure out how poky was setup Jun 24 16:56:40 do you know if it is an exact copy? Jun 24 16:57:01 what's "it" in this context? the script? Jun 24 16:57:10 thwe script Jun 24 16:57:28 then yes, the one in poky comes from oe-core Jun 24 16:57:31 it took me a few gioes to realize that there are more files in the poky repo :) Jun 24 16:58:02 poky is bitbake + oe-core + meta-yocto + yocto-docs, with some light transforms applied en-route Jun 24 16:58:34 yes, but this seems to be a point of confusion (still) Jun 24 16:58:49 agreed Jun 24 16:59:55 Crofton|work: the intent was to make that script autoconfigure depending on the meta directories present, or read the name of the key directory out of a separate config file Jun 24 17:00:08 Crofton|work: I suspect there is a single line difference between the OE and poky versions Jun 24 17:00:09 rp sure Jun 24 17:00:48 we just need to make sure people understand how the pieces fit togetehr Jun 24 17:00:56 ah, top level is the same, scripts/oe-setup-builddir ../poky/scripts/oe-setup-builddir have one line different Jun 24 17:01:13 was really just a time question to go and fix it Jun 24 17:01:21 I was confused because I ahd never looked at the poky repo :) Jun 24 17:01:53 -TEMPLATECONF=${TEMPLATECONF:-meta/conf} Jun 24 17:01:53 +TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf} Jun 24 17:02:17 need to put "meta-yocto/conf" into a config file in the rootdir Jun 24 17:02:26 I actually grepped oe-core for "yocto" Jun 24 17:03:31 rp btw Jun 24 17:03:33 meta/recipes-multimedia/libomxil/libomxil-0.9.3/configure-fix.patch:| i586-poky- Jun 24 17:03:33 linux-libtool: compile: i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/yo Jun 24 17:03:34 cto-build5/poky/build/tmp/sysroots/qemux86 -DHAVE_Climinate-unused-debug-types - Jun 24 17:03:34 Wall -Werror -DCONFIG_DEBUG_LEVEL=0 -c OMXComponentRMExt.c -fPIC -DPIC -o .libs Jun 24 17:03:46 this seems odd Jun 24 17:04:21 Crofton|work: comments in a patch header? Jun 24 17:04:51 yep Jun 24 17:05:05 stream on conciousness Jun 24 17:05:06 Crofton|work: the patch itself or the header? Jun 24 17:05:09 looks like a log fragment from someone's build Jun 24 17:05:12 header Jun 24 17:05:29 its just a cut and paste from someone's build as rburton says Jun 24 17:05:56 Its not a bad way to show what problem the patch solves Jun 24 17:08:17 yeah Jun 24 17:08:25 I just saw it via grep Jun 24 17:09:32 there's no gotcha with replacing a do_install_append() that immediately checks PN against foo-native with do_install_append_class-native, is there? Jun 24 17:12:38 while we are talking about poky, anyone know why it messes with the linuxlibc-headers? Jun 24 20:07:23 otavio: happy birthday ! ;) Jun 24 20:54:12 abelloni: :-D thx a lot :) Jun 24 21:07:16 anyone know the reasoning behind root's home directory being /home/root instead of /root? Jun 24 21:10:24 evanp: historical reasons I think Jun 24 21:10:43 evanp: when OE was used produce OSes for handhelds it was customary for the main user to be root, so if you wanted the home directory to be on a separate partition the thinking was then it should be under /home Jun 24 21:11:00 IIRC Jun 24 21:11:14 I think that's correct Jun 24 21:11:49 if we're lucky there'll be a commit message confirming that in the OE-Classic repo :) Jun 24 21:15:06 hmm, I think it was too early for that Jun 24 21:18:10 hehe Jun 24 21:19:23 evanp: you may already be aware, but you can set ROOT_HOME to change the default Jun 24 21:27:59 bluelightning: in what version of Yocto was ROOT_HOME introduced? Jun 24 21:34:20 bluelightning: looks like 1.4 Jun 24 21:35:13 getting tired of using 1.2...just another few months, hopefully.... Jun 24 22:31:28 evanp: ah yes it was relatively recently Jun 24 22:31:49 evanp: I think that was a pretty simple patch though, would probably be fairly easy to backport if you wanted to Jun 24 22:38:33 khem, otavio: either of you around? Jun 24 22:52:07 halstead: you around? Jun 24 22:52:21 sgw_, Yes. Jun 24 22:52:55 halstead: who's kernel.org maintainer? It looks like the Jun 24 22:53:03 pcmcia files have gone awol Jun 24 22:53:14 http://kernel.org/pub/linux/utils/kernel/pcmcia/pcmciautils-018.tar.bz2 Jun 24 22:53:29 halstead: is not there any more, i can find it on a mirror Jun 24 22:55:30 sgw_, Looking into it. Jun 24 23:06:44 halstead: thanks Jun 24 23:09:36 sgw_, mricon is the main k.org maintainer. He is off today but this should be addressed tomorrow. Jun 24 23:12:33 halstead: thanks Jun 24 23:32:03 I've got this recipe with a do_install that extracts a tarball of binaries etc. Packaging fails with "QA Issue: thething rdepends on anotherthing-dev", I assume because the tarball contains a .so of the same name as anotherthing. Jun 24 23:33:15 What's not clear to me is why it thinks the package depends on anotherthing-dev, since everything in the tarball is self-contained (no deps not also in the tarball) Jun 24 23:34:18 I tried to work around it with EXCLUDE_FROM_SHLIBS = "1" and RPMSPEC_PREAMBLE() { %define __find_provides %{nil} %define __find_requires %{nil} } Jun 24 23:34:39 evanp: I am checking something Jun 24 23:35:47 evanp: do you have any RDEPENDS in your recipe? Jun 24 23:36:23 sgw_: nope. Jun 24 23:37:17 evanp: if you do a bitbake -e | grep ^RDEPENDS do you get anything Jun 24 23:38:06 sgw_: nope. Jun 24 23:39:41 sgw_: well, nothing except for RDEPENDS_thething-staticdev="thething-dev (= X.Y)" and a similar line for the -dev, per usual Jun 24 23:41:54 I am currently assuming there's some magic in package.bbclass, similar to that disabled by EXCLUDE_FROM_SHLIBS, which overwrites RDEPENDS in the context of packaging...hard to follow the dataflow, though Jun 24 23:41:56 evanp: Ok, I was looking at the actual test in insane.bbclass Jun 24 23:46:03 evanp: can you change your packaging and properly package the .so into it's -dev? You can do this by adding package to PACKAGES += ... and then add a FILES_anotherthing-dev = "anotherthing.so" Jun 24 23:48:14 sgw_: not really... anotherthing and anotherthing-dev _do_ install their .so, its just that this giant tarball happens to contain a .so of the same name in a non-standard path (like 6 deep in /opt) Jun 24 23:51:09 and there are programs in the giant tarball which need that .so at runtime, of course Jun 24 23:52:51 evanp: it's a tarball the packaging to rpms happen after the tarball is unpacked in the workdir, so you should be able to the FILES, are the .so links or are they actual libraries Jun 24 23:55:26 sgw_: both. its more or less a tarball of cross-toolchain stuff for a different architecture. Jun 25 00:08:20 evanp: you can also set INSANE_SKIP_thing = "dev-deps" which will ignore this test unless you believe it needs to be fixed Jun 25 00:14:32 sgw_: If I disable dev-deps, then the RPM ends up with a Require: that it technically shouldn't have--that is, the QA error is a real problem\ Jun 25 00:16:59 evanp: hmm, is your recipe and tarball sharable (I understand if it's not) sometimes these things are easier to diagnose with the bits and breakage. Jun 25 00:24:25 sgw_: it is, but getting approval for it to leave the building other than through the official release process would be...interesting.... Jun 25 00:24:43 evanp: I kind of expected that, so never mind Jun 25 00:29:51 sgw_: do you know of anything other than the code disabled by EXCLUDE_FROM_SHLIBS that might inject RDEPENDS into a recipe? Jun 25 00:37:39 evanp: honestly, this is not me deep area, might write up an email and send it to the Yocto list, be sure to summarize and include log files if you can. Jun 25 01:02:32 hmm. looks like it's probably package_do_pkgconfig finding a .pc file somewhere. Jun 25 01:31:16 confirmed. PACKAGEFUNCS := "${@'${PACKAGEFUNCS}'.replace('read_shlibdeps', '')}" in my recipe works around it. Not too terrible, I guess.... **** ENDING LOGGING AT Tue Jun 25 02:59:58 2013