**** BEGIN LOGGING AT Wed Jun 05 02:59:58 2013
Jun 05 07:58:49 <bluelightning> morning all
Jun 05 08:12:24 <Net147> moin
Jun 05 09:33:17 <mckoan> good morning
**** BEGIN LOGGING AT Wed Jun 05 13:15:45 2013
Jun 05 13:28:52 <pt> hi
Jun 05 13:29:15 <pt> BBCLASSEXTEND=nativesdk, what will it build?
**** BEGIN LOGGING AT Wed Jun 05 13:36:47 2013
**** BEGIN LOGGING AT Wed Jun 05 14:29:27 2013
Jun 05 14:38:04 <zsyed> LIC_FILES_CHKSUM points to an invalid file, any idea for this error?
Jun 05 14:38:21 <zsyed> while building image with my own recipe
Jun 05 14:39:17 <Zagor> zsyed: does your recipe contain a LICENSE line with a checksum check?
Jun 05 14:39:50 <Zagor> I mean LIC_FILES_CHKSUM line
Jun 05 14:40:30 <zsyed> yes, it has LIC_FILES_CHKSUM. I am using hello world recipe to build.
Jun 05 14:40:58 <zsyed> i ran md5sum against COPYING and entered in it md5 of recioe
Jun 05 14:41:46 <Zagor> can you show us the complete line?
Jun 05 14:42:04 <zsyed> i downloaded hello-2.7 from here ftp://ftp.gnu.org/gnu/hello/ , extracted and ran md5sum
Jun 05 14:42:25 <zsyed> ERROR: Function failed: hello: LIC_FILES_CHKSUM points to an invalid file: /home/siguser/yocto2013-05-08/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/hello-1.0-r0/hello-1.0/COPYING
Jun 05 14:42:59 <Zagor> I mean the LIC_FILES_CHKSUM line in your recipe
Jun 05 14:43:21 <zsyed> LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
Jun 05 14:44:31 <Zagor> does /home/siguser/yocto2013-05-08/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/hello-1.0-r0/hello-1.0/COPYING exist, and does it have that md5 sum?
Jun 05 14:48:29 <zsyed> No, there is no COPYING file in that hello folder.
Jun 05 14:49:02 <zsyed> is that right? what you are asking for?
Jun 05 14:51:14 <Zagor> zsyed: yes. that's why it complains.
Jun 05 14:52:43 <zsyed> but, according to me it fetches tarball from that url, and do_install() it. why should I add COPYING file?
Jun 05 14:52:53 <zsyed> please correct me if i am wrong
Jun 05 14:53:46 <Zagor> you should add copying file. the point of LIC_FILES_CHKSUM is to check that the license file in the tarball is the same as when the recipe was written
Jun 05 14:53:58 <Zagor> sorry, *should not* add copying
Jun 05 14:56:35 <zsyed> so, i downloaded hello-2.7 got md5sum of COPYING, and added that md5 to my recipe. Isn't how this is done?
**** BEGIN LOGGING AT Wed Jun 05 15:48:30 2013
**** BEGIN LOGGING AT Wed Jun 05 15:56:07 2013
Jun 05 16:16:34 <tharvey> I'm trying to build 'ntp' which is provided in my sources via meta-openembedded/meta-networking/recipes-support/ntp/ntp_4.2.6p5.bb which builds via bitbake -b, yet 'bitbake ntp' says nothing provides ntp - what am I missing?
Jun 05 16:16:51 <tharvey> I'm looking for the ntpclient util or perhaps another way to set system time from a time server
Jun 05 16:17:17 <sgw2> tharvey: I assume you have updated your bblayers.conf to include the meta-networking layer?
Jun 05 16:18:00 <tharvey> uh... no ;P - thanks!
Jun 05 16:18:38 <sgw_> tharvey: yeah you need that for bitbake to find the layer, the -b option says go look in this recipe directly
Jun 05 16:18:57 <tharvey> makes sense... still getting used to the layers - been away from oe for a couple of years
Jun 05 16:19:15 <sgw_> tharvey: no worries, glad to help.
Jun 05 16:19:22 <bluelightning_> tharvey: my advice is always not to use -b unless you really know you want to :)
Jun 05 16:19:41 <tharvey> agreed
Jun 05 16:21:14 <kergoth> and even if you thin kyou want to, you probably don't
Jun 05 16:21:16 <kergoth> :)
Jun 05 16:52:07 <syed_siguser> i am getting LIC_FILES_CHKSUM points to an invalid file, error while building my image,
Jun 05 16:54:02 <syed_siguser> i am trying to add hello world recipe, I downloaded tarball from ftp://ftp.gnu.org/gnu/hello/, md5sum against COPYING and added to LIC_FILES_CHKSUM
Jun 05 16:56:44 <sgw_> syed_siguser: Ok sounds good so far, what's the actual error?  and your LIC_FILES_CHKSUM line?
Jun 05 17:19:05 <sgw_> otavio: regarding the libx11 dependency, seems there was still another bit of investigation on that one also, to ensure it's disabled via the autoconf scripts
Jun 05 18:40:06 <siguser> i am getting LIC_FILES_CHKSUM points to an invalid file, error while building my image,
Jun 05 18:40:14 <siguser>  i am trying to add hello world recipe, I downloaded tarball from ftp://ftp.gnu.org/gnu/hello/, md5sum against COPYING and added to LIC_FILES_CHKSUM
Jun 05 18:40:24 <siguser> after build started i get  LIC_FILES_CHKSUM points to an invalid file error, any Ideas?
Jun 05 19:06:34 <florinsarbu> Hello.
Jun 05 19:06:38 <florinsarbu> Anyboady around?
Jun 05 19:07:19 <siguser> ya
Jun 05 19:07:36 <florinsarbu> any idea why do we have in qemu.bbclass
Jun 05 19:07:42 <florinsarbu> " libdir = rootfs_path + data.getVar("libdir", False)"
Jun 05 19:07:53 <florinsarbu> which makes sense
Jun 05 19:07:53 <siguser> ya
Jun 05 19:07:59 <florinsarbu> any idea why do we have in qemu.bbclass
Jun 05 19:08:04 <florinsarbu> " libdir = rootfs_path + data.getVar("libdir", False)"
Jun 05 19:08:18 <florinsarbu> which makes sense on a 32 machine but not on a 64
Jun 05 19:09:23 <siguser> No idea about that, i am noob here,
Jun 05 19:09:25 <florinsarbu> pseudo lib on a 64 host is installed in /usr/lib/pseudo/lib64
**** BEGIN LOGGING AT Wed Jun 05 19:31:19 2013
Jun 05 19:55:49 <florinsarbu> Still no PSEUDO gurus around?
Jun 05 19:55:54 <seebs> eh?
Jun 05 19:56:15 <florinsarbu> hello seebs
Jun 05 19:56:31 <florinsarbu> here's a very strange behavior
Jun 05 19:56:38 <seebs> If you have a pseudo question, the answer is "it's user error". <-- I have found this works about 80% of the time.
Jun 05 19:57:26 <florinsarbu> just want to know who tells pseudo to check for lib in pseudo/lib64 on a 64 machine
Jun 05 19:57:50 <seebs> That's sort of built-in. There is a historical reason here.
Jun 05 19:58:26 <florinsarbu> that's good news
Jun 05 19:58:37 <seebs> We want to be able to add pseudo's library director(y|ies) to LD_LIBRARY_PATH *without* putting any other libraries in the path.
Jun 05 19:59:11 <seebs> If we just used the generic lib directory for our sysroot, then host binaries trying to run under pseudo would (sometimes) get linked against yocto build system libraries, which could result in catastrophic failures if they're different.
Jun 05 19:59:36 <seebs> This was a bigger deal in the internal WR build system, where we would ship prebuilt host tools with a set of libraries that might not be as new as the native libraries on some hosts.
Jun 05 20:00:02 <florinsarbu> WR... as in WRS?
Jun 05 20:00:05 <seebs> Then pseudo internally knows enough to look for a lib and a lib64, on 64-bit hosts, because a 32-bit process could exec a 64-bit process.
Jun 05 20:00:18 <florinsarbu> git that now
Jun 05 20:00:21 <seebs> Yeah. Pseudo was originally developed for use with the Wind River build system.
Jun 05 20:00:21 <florinsarbu> got*
Jun 05 20:00:34 <florinsarbu> i know - i'm wrs :)
Jun 05 20:00:36 <florinsarbu> anyway
Jun 05 20:00:37 <florinsarbu> another q, if i may, what is PSEUDO_UNLOAD=1? where can i see this documented? or maybe you can help me with a hint
Jun 05 20:00:50 <seebs> So the reason there's a lib/pseudo/lib and lib/pseudo/lib64 is in case we need to run 32-bit binaries.
Jun 05 20:00:59 <seebs> Which mostly comes up because our prebuilt binary toolchain is all 32-bit.
Jun 05 20:01:24 <seebs> PSEUDO_UNLOAD tells pseudo to change the environment so that, after an exec(), it won't be loaded.
Jun 05 20:01:49 <seebs> It should be documented in the pseudo man page.
Jun 05 20:02:03 <florinsarbu> i understand, now, i get a very strange error when installing udev-hwdb
Jun 05 20:02:05 <seebs> $ nroff -man pseudo.1 | more
Jun 05 20:02:15 <florinsarbu> actually when running post install
Jun 05 20:02:29 <florinsarbu> which runs qemu_run_binary
Jun 05 20:03:52 <florinsarbu> and the rootfs fails with cann't preload libpseudo.so
Jun 05 20:03:52 <florinsarbu> if i remove this post install it works
Jun 05 20:03:52 <florinsarbu> is happens after my last sync
Jun 05 20:03:52 <seebs> Okay. This sounds like it's likely specific to our build system or current tree, in which case we should probably move to the WR IRC server because this will be of marginal utility to anyone else.
Jun 05 20:04:16 <florinsarbu> how come
Jun 05 20:04:32 <seebs> Because they're probably not using our tree, and a lot of the stuff we encounter is specific to local color.
Jun 05 20:04:32 <florinsarbu> current master fails in this way if you want to include this package in an image...
Jun 05 20:04:46 <florinsarbu> i'm using oe-core master
Jun 05 20:04:57 <florinsarbu> + meta=fsl-arm + meta-ivi
Jun 05 20:05:05 <florinsarbu> So nothing specific.
Jun 05 20:05:06 <seebs> Oh. Hmm. Well, one difference I know of, we set NO32LIBS = 0, oe-core defaults to 1.
Jun 05 20:05:25 <florinsarbu> DId that - nothing
Jun 05 20:05:31 <seebs> Hmm.
Jun 05 20:06:39 <seebs> Okay, I can look at this more, but possibly not immediately. Can you email me instructions to reproduce it in more detail? I'll need to poke around inside a build for a while to see if I can find something. It's totally possible something's broken, but I don't think I've seen any fail-to-load messages recently.
Jun 05 20:08:03 <florinsarbu> do you have a 64 bit host at your disposal?
Jun 05 20:08:08 <seebs> Lots!
Jun 05 20:08:45 <florinsarbu> :)
Jun 05 20:08:55 <seebs> What I have to work for these days is finding a 32-bit host.
Jun 05 20:09:49 <florinsarbu> correct - so to reproduce is as simple as baking an image including this package (udev-hwdb)
Jun 05 20:10:25 <florinsarbu> i tried fresh builds, i tried everything... :|
**** BEGIN LOGGING AT Wed Jun 05 21:22:53 2013
**** ENDING LOGGING AT Thu Jun 06 02:59:58 2013