**** BEGIN LOGGING AT Thu Apr 02 02:59:58 2015
Apr 02 04:35:28 <xulfer> Hm trying to boot a yocto image from core-image-minimal-initramfs.  However once the boot media loads nothing seems to happen.  The yocto image I'm planning to boot has been tested to work.  Is there a script I need to modify or something to move init along?
Apr 02 04:45:55 <redengin> xulfer, whats the last message you see?
Apr 02 04:46:47 <xulfer> kernel messages about the removable media.
Apr 02 04:46:51 <xulfer> aka the root i want
Apr 02 04:46:55 <xulfer> so i'm assuming init isn't getting handed off
Apr 02 04:48:39 <redengin> do you see it mounting?
Apr 02 04:50:02 <xulfer> yes.  well i believe so.  i get the ext-3 messages and what not after waiting for removable.
Apr 02 04:50:49 <redengin> and you made the media by burning the iso?
Apr 02 04:51:35 <xulfer> no, arm booting
Apr 02 04:51:41 <xulfer> so copy initramfs into boot dir
Apr 02 04:51:48 <xulfer> then tar into mmc
Apr 02 04:52:41 <redengin> did you also create the root filesystem?
Apr 02 04:53:02 <redengin> or does your initramfs contain everything?
Apr 02 04:53:19 <xulfer> no.  just the kernel from the bsp, then the rootfs has everything else
Apr 02 04:53:24 <xulfer> was also wondering if i'm missing something
Apr 02 04:53:30 <xulfer> since before today the rootfs WAS the initramfs
Apr 02 04:54:16 <nrossi> xulfer: the -initramfs target is generally for rootfs pivoting
Apr 02 04:54:18 <redengin> usually the initramfs is just the bootstrapping code and then it mounts the rootfs to complete, but I've also seen people build the rootfs into the initramfs
Apr 02 04:54:29 <redengin> unfortunately I don't know how to do that in yocot
Apr 02 04:54:50 <xulfer> nrossi, oh.  in my rootfs, or core-image-minimal-initramfs
Apr 02 04:55:11 <nrossi> xulfer: you need to have two rootfs, the core-image-minimal-initramfs and <your rootfs>
Apr 02 04:55:22 <xulfer> yeah i do
Apr 02 04:55:29 <xulfer> however the second doesn't seem to be starting up
Apr 02 04:55:47 <nrossi> have you loaded the content onto the second rootfs?
Apr 02 04:55:53 <xulfer> yes
Apr 02 04:56:01 <xulfer> it's on the emmc, takes up the whole thing
Apr 02 04:56:50 <xulfer> are there more details i can provide somehow?  the init screen is obviously a bit vague
Apr 02 04:57:25 <nrossi> got the whole boot log?
Apr 02 04:58:12 <xulfer> i can get it here in a moment.  i think the everything is still the same on my device.
Apr 02 04:58:54 <redengin> can you serial it out and paste it?
Apr 02 05:02:02 <xulfer> yeah that's the plan.  will do
Apr 02 05:25:03 <xulfer> sorry for the delay guys.
Apr 02 05:25:14 <xulfer> on a windows machine and wasn't quite familiar with how to do this on windows.
Apr 02 05:25:51 <xulfer> http://pastebin.com/HBFz8cqa
Apr 02 05:25:55 <xulfer> that's my boot log currently
Apr 02 05:35:00 <redengin> is the rootfs on mmcblk1p1 or mmcblk1p2?
Apr 02 05:35:12 <nrossi> xulfer: looks like it hasn't found the mount, see the polling here: https://github.com/openembedded/oe-core/blob/d4f4ad5edd8914e696722c1a1c3ba7de091d4c19/meta/recipes-core/initrdscripts/files/init-live.sh#L118
Apr 02 05:36:57 <xulfer> hmm
Apr 02 05:37:14 <xulfer> yeah that looks right.  i'm not sure how that's happening though.
Apr 02 05:38:07 <xulfer> is there something i need to setup in the initramfs image itself?  I just noticed it's finding both the sdcard, and the device i'm trying to use as root.
Apr 02 05:44:05 <nrossi> hmmm i dont think the core-image-minimal-initramfs is intended for ARM
Apr 02 05:45:25 <xulfer> yeah i had to modify it.
Apr 02 05:45:32 <xulfer> but i'm trying to accomplish similar
Apr 02 05:45:51 <xulfer> we want a fallback image.  so the idea is to have an initramfs that could hold an http and what not supposing boot fails for firmware updates.
Apr 02 05:46:01 <xulfer> and have a writable larger rootfs
Apr 02 05:46:51 <nrossi> xulfer: ah ok so you probably intend to write your own initramfs boot scripts aways
Apr 02 05:48:07 <xulfer> yeah I might have to.  was hoping to avoid that though. :)
Apr 02 05:48:45 <xulfer> the support for this board is pretty crappy so my options with this type of stuff is very limited.
Apr 02 05:49:29 <xulfer> Not from yocto.  The board manufacturer only supports an old version of ubuntu, etc, etc.  Already had to write a BSP.  It's turned into quite the money pit.
Apr 02 05:49:51 <nrossi> it looks like if you throw the rootfs onto the partition as an img file it will mount that... it seems this is more setup for live images as opposed to switch root.
Apr 02 05:50:02 <xulfer> yeah
Apr 02 05:50:07 <nrossi> has to be called "rootfs.img"
Apr 02 05:50:14 <xulfer> hmm but that would be read only yes?
Apr 02 05:50:29 <nrossi> not nessecarily.... unless it mounts it ro, let me check
Apr 02 05:51:13 <nrossi> it mounts it rw with an additional overlayfs setup
Apr 02 05:51:23 <nrossi> so you have rootfs.ro and rootfs.rw mounts
Apr 02 05:51:35 <nrossi> https://github.com/openembedded/oe-core/blob/d4f4ad5edd8914e696722c1a1c3ba7de091d4c19/meta/recipes-core/initrdscripts/files/init-live.sh#L170
Apr 02 05:51:59 <xulfer> ahh so i have to do it by hand.
Apr 02 05:52:03 <xulfer> stuck with a 3.4 kernel
Apr 02 05:52:29 <nrossi> it has a fallback to tmpfs
Apr 02 06:00:21 <xulfer> hm ok
Apr 02 07:53:20 <andrei_> Hello
Apr 02 07:53:45 <andrei_> I have added a recipe to include a new package into an already existent image
Apr 02 07:53:48 <andrei_> and I get this ERROR: unixodbc not found in the base feeds (t1040rdb ppce5500 powerpc noarch any all).
Apr 02 07:53:57 <andrei_> unixodbc is the package I added.
Apr 02 07:54:09 <andrei_> I checked under ${WORKDIR}/image
Apr 02 07:54:12 <andrei_> and the files look ok
Apr 02 07:54:16 <andrei_> but I can't find the rpm
Apr 02 07:54:54 <andrei_> any clue why?
Apr 02 08:10:17 <andrei_> if I put ALLOW_EMPTY_${PN} = "1" in the recipe it works
Apr 02 08:10:27 <andrei_> but I don t have anything on my uImage
Apr 02 08:15:26 <bluelightning> andrei_: missing stuff in do_install perhaps?
Apr 02 08:15:30 <bluelightning> (morning all)
Apr 02 08:15:39 <andrei_> bluelightning: hey !
Apr 02 08:15:45 <andrei_> 	     oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} \             INCLUDEDIR=${includedir}
Apr 02 08:15:53 <andrei_> this is what I do in do_install
Apr 02 08:18:22 <bluelightning> ok, so then I would check ${D} (which is the "image" subdirectory under the workdir for the recipe) to see what is ending up in there
Apr 02 08:18:48 <bluelightning> if you're not sure where the workdir is you can find that by running bitbake -e recipename | grep ^WORKDIR=
Apr 02 08:22:18 <andrei_> I'm in my image subdir
Apr 02 08:22:32 <andrei_> I got usr/local/bin /include /share and /lib
Apr 02 08:22:38 <andrei_> do_install completes ok
Apr 02 08:22:44 <andrei_> do_rootfs fails because it can't find a rpm
Apr 02 08:22:49 <andrei_> I ll post my whole recipe
Apr 02 08:23:18 <andrei_> http://pastebin.com/b41LHWHs
Apr 02 08:24:42 <andrei_> http://pastebin.com/t2zQ8b3M here's the dirtree in img
Apr 02 08:24:44 <andrei_> imo, it looks ok
Apr 02 08:31:47 <bluelightning> andrei_: /usr/local? generally you should be installing into /usr rather than /usr/local
Apr 02 08:31:57 <bluelightning> are you receiving any warnings?
Apr 02 08:32:04 <bluelightning> (I'd be surprised if you weren't)
Apr 02 08:32:39 <andrei_> nope, not related to this packages. Just that it skips three other packages for which I ( intended to) leave symbols undefined
Apr 02 08:32:44 <andrei_> this package*
Apr 02 08:33:56 <andrei_> I didn't install it to usr/local on purpose, I assume {D} is the variable responsible for that, but how can I change it to be correct?
Apr 02 08:34:03 <bluelightning> have you disabled any warnings?
Apr 02 08:34:58 <bluelightning> because if you are putting files in /usr/local and haven't taken steps to package that directory (and I see none in the recipe) you should have received a warning
Apr 02 08:35:25 <andrei_> no, I didn't. It's the Freescale SDK and I haven't changed anything except of this recipe
Apr 02 08:35:31 <andrei_> what you're saying makes sense
Apr 02 08:35:57 <bluelightning> ok, what is WARN_QA set to?
Apr 02 08:36:45 <bluelightning> and ERROR_QA
Apr 02 08:39:05 <andrei_> they are set in poky/meta-yocto/conf/ .. ?
Apr 02 08:39:58 <bluelightning> well, easiest is just to run bitbake -e | grep ^WARN_QA=
Apr 02 08:40:26 <andrei_> ah, poky.conf
Apr 02 08:40:27 <andrei_> found it
Apr 02 08:40:44 <andrei_> WARN_QA = "textrel files-invalid incompatible-license xorg-driver-abi libdir \            unknown-configure-option"
Apr 02 08:40:56 <bluelightning> there's no guarantee that is the only place it is set/modified, hence why I suggested bitbake -e
Apr 02 08:41:05 <andrei_> okay
Apr 02 08:41:16 <andrei_> sorry, I'm kind of a yocto newbie, but you probably figured that out
Apr 02 08:41:26 <bluelightning> no worries
Apr 02 08:41:43 <andrei_> $ bitbake -e | grep ^WARN_QA=
Apr 02 08:41:43 <andrei_> WARN_QA="textrel files-invalid incompatible-license xorg-driver-abi libdir unknown-configure-option"
Apr 02 08:42:06 <bluelightning> ok, what about ERROR_QA?
Apr 02 08:42:56 <andrei_> ERROR_QA="dev-so debug-deps dev-deps debug-files arch la2 pkgconfig la perms rpaths staticdev ldflags"
Apr 02 08:43:04 <bluelightning> sigh
Apr 02 08:43:32 <bluelightning> shoot whoever configured it that way, because the one warning that would have told you what's wrong here is turned off :/
Apr 02 08:44:22 <bluelightning> (installed-vs-shipped)
Apr 02 08:44:31 <andrei_> will do!
Apr 02 08:44:54 <bluelightning> anyway, back to the recipe
Apr 02 08:45:09 <bluelightning> I think what's really wrong here is you should drop your custom do_configure
Apr 02 08:45:47 <bluelightning> then the correct prefixes will be passed in by the default implementation from autotools.bbclass (among many other default arguments that you really need) and it should then install to /usr rather than /usr/local
Apr 02 08:46:19 <andrei_> I tried dropping the custom do configure
Apr 02 08:46:24 <andrei_> I get a libtoolize error
Apr 02 08:46:34 <andrei_> that it needs to regenerate some a4.local
Apr 02 08:46:51 <andrei_> You should recreate aclocal.m4 with macros from libtool 2.2.6
Apr 02 08:56:04 <bluelightning> andrei_: I wonder if libtoolize --force in a do_configure_prepend() would work?
Apr 02 09:01:13 <bluelightning> nope, apparently not
Apr 02 09:03:05 <andrei_> just a sec, I'm trying without a custom config to see the exact error
Apr 02 09:04:02 <andrei_> Version mismatch error.  This is libtool 2.4.2, but the
Apr 02 09:04:12 <andrei_> | libtool: definition of this LT_INIT comes from libtool 2.2.6.
Apr 02 09:04:18 <andrei_> | libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 | libtool: and run autoconf again.
Apr 02 09:06:11 <andrei_> wouldn't  FILES_${PN} += "/usr/local" work ?
Apr 02 09:07:08 <bluelightning> that's not the only issue with this
Apr 02 09:07:28 <bluelightning> here is a patch adding a recipe that someone else wrote recently: http://patchwork.openembedded.org/patch/88215/
Apr 02 09:08:16 <bluelightning> except that doesn't work either :/
Apr 02 09:11:23 <joshuagl> todor: around? I'm hoping to ask you about the Eclipse plugin
Apr 02 09:12:45 <joshuagl> first question would be whether Luna will be supported for 1.8? :-)
Apr 02 09:16:37 <andrei_> bluelightning: one of the reason that doesn't work is (in my case) it lacks host_alias
Apr 02 09:19:42 <bluelightning> andrei_: this is crusty old software unfortunately :(
Apr 02 09:19:59 <bluelightning> andrei_: there does seem to be a patch upstream to update libtool, I'm just trying to extract it
Apr 02 09:23:42 <andrei_> hm.FILES_${PN} += "${WORKDIR}/image/usr/local" doesn't work
Apr 02 09:27:50 <bluelightning> did you try oe_runconf instead of ./configure ?
Apr 02 09:28:52 <andrei_> no, I m going to try that now
Apr 02 09:29:06 <andrei_> I tried something rather hackish as well. I copied * from  local to usr
Apr 02 09:29:08 <andrei_> and still same error
Apr 02 09:30:26 <andrei_> do_compiles fails with
Apr 02 09:30:33 <andrei_> oe_runconf
Apr 02 09:30:51 <andrei_> I get a lot of undefined references
Apr 02 09:31:06 <andrei_> SQL related, mostly
Apr 02 09:35:45 <bluelightning> ok, I'm giving up at this point, this software is horrifically broken
Apr 02 09:36:52 <andrei_> well, bluelightning, thanks a lot for your help ! I appreciate it. Hopefully, if I get it working, I'll get back with a recipe
Apr 02 09:37:33 <bluelightning> ok, thanks
Apr 02 09:38:01 <bluelightning> FYI I cloned the upstream repo with: git svn clone svn://svn.code.sf.net/p/unixodbc/code/trunk unixodbc-code
Apr 02 09:38:23 <bluelightning> they have a libtool update patch, but (a) it doesn't apply without hacking and (b) when it's fixed so that it does, the thing still doesn't build
Apr 02 09:38:49 <bluelightning> you might also need to inherit autotools-brokensep rather than autotools, I'm not sure
Apr 02 09:39:25 <bluelightning> in any case, you definitely don't want to be building without the correct configure arguments
Apr 02 09:39:58 <andrei_> I built  unixodbc  on my host and it installed succesfully
Apr 02 09:41:07 <bluelightning> yeah, building on the host is always easier than cross-building ;)
Apr 02 09:42:43 <andrei_> makes sense
Apr 02 10:29:15 <pev> hey all
Apr 02 10:30:31 <pev> quick one - in a default build of yocto, the system uses it's password auth from busybox right? It looks like my build is using crypt but should really use MD5. Is there a standard yocoto mechanism to select / change this or should I just go in and hack / patch busybox directly?
Apr 02 10:47:06 <andrei_> I have SRC_URI = "file:///home/andrei/Downloads/unixODBC-2.3.2.tar.gz"
Apr 02 10:47:15 <andrei_> file exists and is readable (644)
Apr 02 10:47:29 <andrei_> recipe is built, but in my {WORKDIR}
Apr 02 10:47:33 <andrei_> there is no source folder
Apr 02 10:47:41 <andrei_> is there any warning to SRC_URI related that I can enable?
Apr 02 10:48:30 <todor> joshuagl: hello.. yes there are plans to support luna for 1.8
Apr 02 10:48:49 <joshuagl> todor: super, that's good to hear. thanks :-)
Apr 02 10:49:03 <joshuagl> todor: will you be creating a public roadmap/schedule for future development?
Apr 02 10:50:42 <todor> joshuagl: we have some new features in the pipeline, but it is a bit early for a roadmap. please keep an eye on the mailing list for the announcements
Apr 02 10:51:33 <joshuagl> todor: OK, cool - yocto@ ? The reason I asked about a roadmap is it may make it easier for others to contribute
Apr 02 10:53:09 <todor> joshuagl: i understand.. we'll try to publish a schedule soon.. Yup the ML is yocto@yoctoproject.org
Apr 02 10:53:50 <joshuagl> todor: great, thanks. I look forward to hearing what's planned for Eclipse support :-)
Apr 02 10:56:08 <todor> joshuagl: no problem..
Apr 02 11:14:13 <Lev___> Hi there
Apr 02 11:14:59 <Lev___> tmpsantos: you're maintaining crosswalk metalayer right? I have troubles building it, could you take a look?
Apr 02 11:15:20 <tmpsantos> Lev___: hi there
Apr 02 11:16:00 <tmpsantos> Lev___: I don't work for intel anymore but I could have a look
Apr 02 11:33:56 <andrei_> hm, sorry to get back with the same issue over and over but I simply can't understand what's happening
Apr 02 11:34:05 <Lev___> I'm trying to compile it for the armv7 target and I get linker errrors, it seems to be using the host linker with the host -L paths... I
Apr 02 11:34:34 <andrei_> I got this recipe http://pastebin.com/QJG3mzYt which configures, compiles and installs ok
Apr 02 11:34:47 <andrei_> but I keep getting WARNING: QA Issue: unixodbc: Files/directories were installed but not shipped
Apr 02 11:34:56 <andrei_> how can I fix that? what's happening
Apr 02 11:35:23 <Lev___> tmpsantos: like this: /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so when searching for -lstdc++
Apr 02 11:35:58 <Lev___> tmpsantos: although the compilation happens with the right compiler..
Apr 02 11:36:18 <Lev___> tmpsantos: any clue where i have to look?
Apr 02 11:38:08 <bluelightning> andrei_: there are files being installed, but not packaged, because they are installed to locations not matched by FILES values
Apr 02 11:38:25 <bluelightning> andrei_: thus they can never appear in the target image
Apr 02 11:38:49 <andrei_> why wouldn't FILES_${PN}v += "/local" work ?
Apr 02 11:39:02 <andrei_> without the v
Apr 02 11:39:03 <andrei_> FILES_${PN} += "/local"
Apr 02 11:39:04 <andrei_> like this
Apr 02 11:39:14 <bluelightning> are the files actually in /local? or /usr/local ?
Apr 02 11:39:51 <bluelightning> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-issue-installed-vs-shipped
Apr 02 11:39:58 <andrei_>  usr/local
Apr 02 11:40:44 <bluelightning> ok, then that is the path you would need to add...
Apr 02 11:41:35 <andrei_> yeah, that worked! Thanks a lot
Apr 02 11:41:47 <andrei_> I thought usr is where it looks, so /local was relative to usr
Apr 02 11:42:01 <bluelightning> no, it looks at whatever is placed in ${D}
Apr 02 11:42:14 <andrei_> I get a ERROR: QA Issue: non -staticdev package contains static .a library because I do indeed have .a
Apr 02 11:42:45 <bluelightning> yes, that is again because of /usr/local
Apr 02 11:43:34 <bluelightning> I appreciate you're trying to solve this in the quickest way possible, but really the least painful is to ensure you have the appropriate configure arguments passed, including the prefix
Apr 02 11:44:33 <andrei_> I'm trying to fix it in the quickest way possible as there are people needing the library to work for other applications
Apr 02 11:45:46 <andrei_> otherwise, I'll try to remove the /local thing, it's not intended, I sort of ended up with it
Apr 02 11:46:46 <andrei_> any reasonable way to fix the error above ?
Apr 02 11:48:31 <andrei_> if I do bitbake -e fsl-image-core | grep ^D=
Apr 02 11:48:52 <andrei_> I get D="mypath/tmp/work/t1040rdb-fsl-linux/fsl-image-core/1.0-r0/image"
Apr 02 11:48:56 <andrei_> which is correct
Apr 02 11:49:00 <andrei_> I don t get where it gets the /local from
Apr 02 11:50:59 <tmpsantos> Lev___: can you paste the error into a gist/pastebin?
Apr 02 11:54:20 <Lev___> tmpsantos: http://pastebin.com/xVyerFNV
Apr 02 11:56:21 <tmpsantos> Lev___: is your host also ARM? because it seems to be using the host compiler instead of the toolchain
Apr 02 11:56:32 <Lev___> nope the host is x64
Apr 02 11:56:37 <Lev___> yes exactly
Apr 02 11:56:41 <Lev___> but I have no idea why
Apr 02 11:56:59 <Lev___> all other recipes build using the cross compiler
Apr 02 11:58:08 <tmpsantos> Lev___: https://github.com/crosswalk-project/meta-crosswalk/commit/362674ee6f838aafdaeae5b8bb035615330d243e
Apr 02 11:58:18 <tmpsantos> I remember fixing this bug here ^
Apr 02 11:59:19 <Lev___> i have that file(it's in master), I was assuming I didn't have to do any manual steps to make it work - do I?
Apr 02 12:01:13 <Lev___> but I'm still kinda new to bitbake and gyp, so seems I missed something...
Apr 02 12:25:32 <andrei_> bluelightning: I got it working, I post it here, http://pastebin.com/WsjrXyTa not sure if it can be useful for anyone but. In any case, thank you for helping me out, it really sped things up
Apr 02 13:01:28 <bluelightning> andrei_: no problem
Apr 02 13:01:49 <andrei_> bluelightning:  it's incredible how many issues I can run into
Apr 02 13:01:57 <andrei_> right now, I figured there is no .so object built at all
Apr 02 13:02:09 <bluelightning> some software is easy to build, some not so much
Apr 02 13:02:09 <andrei_> and it doesn't make any sense why
Apr 02 13:02:37 <bluelightning> yeah libtool can break like that unfortunately :(
Apr 02 13:02:50 <andrei_> so the issue is caused by libtool ?
Apr 02 13:03:22 <andrei_> now it makes sense why I should have compiled it properly ...
Apr 02 13:09:47 <sm0ketst> hi all
Apr 02 13:11:45 <sm0ketst> is there a place where i can find FUSE libs rules?
Apr 02 13:11:57 <sm0ketst> rules/recipes
Apr 02 13:20:03 <bluelightning> sm0ketst: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=fuse
Apr 02 13:20:13 <bluelightning> I would suggest the one from meta-filesystems
Apr 02 13:26:06 <sm0ketst> http://cgit.openembedded.org/meta-openembedded/tree/?h=dizzy
Apr 02 13:26:08 <sm0ketst> ??
Apr 02 13:27:05 <sm0ketst> using dizzy now testing meta-oe and meta-filesystems with my own layers
Apr 02 13:28:14 <sm0ketst> yes the one maintained by Martin Jansa
Apr 02 13:28:18 <sm0ketst> thanks bluelightning
Apr 02 13:49:09 <sm0ketst> bluelightning: my configure is complaining about ---> PKG_CHECK_MODULES(FUSE, fuse), i need to build another recipe AFAIK ??
Apr 02 13:49:19 <_4urele_> hi again does anyone know a package named epoxy?
Apr 02 13:58:49 <bluelightning> sm0ketst: maybe it's not looking in the right place for the pc file?
Apr 02 14:01:23 <andrei_> bluelightning: what do you think is the most reasonable approach to getting that unixodbc recipe to work? Can yocto work with libtool 2.2.6 ? Cheers!
Apr 02 14:02:02 <bluelightning> andrei_: fix unixodbc so it correctly builds with the libtool we are using (which is pretty much the latest)
Apr 02 14:02:48 <andrei_> they don't have an IRC channel and I doubt they offer any support, but I'll try, thanks!
Apr 02 14:03:36 <bluelightning> the thing is they already have a patch upstream that's supposed to do the fix, it just apparently isn't quite working
Apr 02 14:07:30 <jku> _4urele_: I was just packaging epoxy -- last gtk requires it
Apr 02 14:08:03 <_4urele_> jku, :) i'm trying also... but i'm facing an issue at install
Apr 02 14:08:34 <sm0ketst> bluelightning: i think it is ok. Im able to build the fuse pkg from bitbake since no other recipe depends on it. but if i add a dependency (my actual recibe/library) then bb fails with the do_configure. I dont know well the whole process yet. But apparently to build the lib i need to have support for FUSE when doing the configure for that particula lib.
Apr 02 14:09:01 <sm0ketst> bluelightning: I've tried to build the library natively and ./configure works... but im not able from bb
Apr 02 14:10:19 <jku> _4urele_: I'm not an expert but try something like this http://pastebin.com/ENXwjFcP
Apr 02 14:12:33 <bluelightning> sm0ketst: right, I got that
Apr 02 14:13:19 <bluelightning> sm0ketst: if you have fuse in DEPENDS of your recipe, there can be only two reasons it is failing - either the fuse recipe is not installing the pc file, or the software your recipe is building is not looking in the correct location
Apr 02 14:13:25 <bluelightning> i.e. under the sysroot
Apr 02 14:15:32 <_4urele_> jku, i'm not an expert too, but it seems to work, thanks a lot! now I'm facing an error due to missing libx11.
Apr 02 14:17:11 <sm0ketst> bluelightning: going to check, thanks indeed
Apr 02 14:21:26 <bluelightning> sm0ketst: FWIW I just checked here, it does install a pc file
Apr 02 14:23:19 <bluelightning> sm0ketst: you can verify this by looking in PKG_CONFIG_DIR which you can query by running: bitbake -e | grep PKG_CONFIG_DIR=
Apr 02 14:23:29 <bluelightning> there should be a fuse.pc in there
Apr 02 14:26:09 <sm0ketst> bluelightning: yes, it is there
Apr 02 14:28:12 <sm0ketst> bluelightning: maybe i sould define my own do_configure in the .bb instead of use the default one
Apr 02 14:28:28 <bluelightning> sm0ketst: I wouldn't advise that, no
Apr 02 14:28:51 <bluelightning> sm0ketst: the next step would be to look at log.do_configure and config.log to see what kind of test it is actually doing
Apr 02 14:29:34 <sm0ketst> bluelightning: i need also to give ./configure specific options so actually I'm using EXTRA_OECONF to give the -- options
Apr 02 14:29:54 <bluelightning> sm0ketst: sure, EXTRA_OECONF is the way to do that
Apr 02 14:30:20 <sm0ketst> bluelightning: thanks going to check deeper
Apr 02 14:30:25 <bluelightning> for autotools/cmake recipes, overriding do_configure is a last resort
Apr 02 14:48:22 <joshuagl> todor: btw you're not the default assignee for Eclipse bugs in bugzilla.yoctoproject.org
Apr 02 14:48:35 <joshuagl> you probably havne't seen the half a dozen or so I filed yesterday, then
Apr 02 15:14:12 <bluelightning> joshuagl: they just got reassigned :) I've asked Stephen to get the default assignee changed
Apr 02 15:18:19 <todor> joshuagl: all bugs were just assigned to me..
Apr 02 15:24:50 <joshuagl> bluelightning: todor: yup, I just got the change notifications from BZ :-)
Apr 02 15:25:03 <joshuagl> very efficient
Apr 02 15:36:12 <scottrif> halstead: ping
Apr 02 15:38:12 <halstead> scottrif: I'm around in 20 minutes.
Apr 02 15:38:34 <scottrif> thanks.. I am in the office also and can't publish docs to my SSH area.
Apr 02 16:08:48 <kergoth> this makes absolutely no sense. i have two vms. each vm has a centos6 chroot. both are doing bitbake builds in that chroot. did a build on one, copied the sstate to the other, and it's building from scratch instead of using the sstates it has. when it builds from scratch, the created sstates have the same filenames as the existing ones had — that is, the signatures didn't change
Apr 02 16:08:56 <kergoth> and i don't see anything in the logs about a failure to extract or use those sstates
Apr 02 16:08:59 * kergoth digs
Apr 02 16:12:27 <bluelightning> kergoth: same NATIVELSBSTRING I assume?
Apr 02 16:14:51 <halstead> scottrif: what's up?
Apr 02 16:36:50 <khem`> any ideas if we can do an image inside initramfs image sort of thing easily
Apr 02 16:37:20 <rink_> khem`, fwiw, I just use loopback mount for a image file
Apr 02 16:37:25 <rink_> but its not inside initramfs
Apr 02 16:37:49 <khem`> rink_: its about building it
Apr 02 16:38:02 <rink_> oh, no idea there - I build mine externally
Apr 02 16:38:08 <khem`> if we can have it expressed in dependencies for OE
Apr 02 16:38:10 <khem`> properly
Apr 02 16:39:13 <kergoth> bluelightning: yep
Apr 02 16:39:25 <bluelightning> hmm, strange
Apr 02 16:40:06 <kergoth> interestingly, the sstate tarball and siginfo are both present, but when i build, the sstate_checkhashes function says the siginfo isn't there, and then both get rewritten out when it bulids from scratch. checked the exact path/filename — it was present before the build, afaict
Apr 02 16:40:17 <kergoth> it's like it's removing it, then complaining it can't find it, marking it as missing, and trying to fetch it?
Apr 02 16:40:19 * kergoth is confused
Apr 02 16:40:21 * kergoth gets more caffeine
Apr 02 16:42:49 * kergoth wipes tmp and tries again, this time seeing if it can use the sstate it just emitted.. and then will compare the two sstate caches
Apr 02 16:54:29 <kergoth> er.
Apr 02 16:54:33 <kergoth> how did i get into this situation?
Apr 02 16:55:15 <kergoth> rm -rf tmp; bitbake -c populate_sysroot quilt-native; # builds from scratch. do it again, builds from scratch again. SSTATE_DIR is relative to ${COREBASE}/../, outside of tmp
Apr 02 16:55:34 <kergoth> -S printdiff says the changes start at quilt-native:do_fetch, but no details
Apr 02 16:59:56 <nerdboy> https://www.youtube.com/watch?v=owA34B2nDYs  <=  NMA in the morning?
Apr 02 17:02:50 <bluelightning> kergoth: kind of sounds like something is wrong at the fetching end of things
Apr 02 17:52:17 <kergoth> gah
Apr 02 17:57:26 <kergoth> if i define SSTATE_DIR, it works, if i defined SSTATE_DIR_forcevariable, it doesn't. i suspect part of the sstate code is working with finalized data, and part of it is not
Apr 02 17:57:31 <kergoth> s/defined/define/
Apr 02 17:57:39 * kergoth digs further
Apr 02 18:43:02 <p1ra> is there a python3 recipe that actually works? Many of the packages listed by 'bitbake -e python3  | grep ^PACKAGES= ' are missing
Apr 02 19:04:00 <mkaras> How do I install a custom python package in yocto?  I've tried looking up google but nothing comes up.  On my non-target machine I just do pip install <package-folder>.  What do I put in my bb file?
Apr 02 19:07:53 <realBigfoot> is there a way to force fetch master repo of a recipe ?
Apr 02 19:08:12 <realBigfoot> something like bitbake image -c do_fetch -f
Apr 02 19:08:44 <kergoth> what do you mean by 'master repo'?
Apr 02 19:09:52 <kergoth> RP: I just had an idea for a prototype, opt-in bitbake feature on the walk up to the coffee shop: block access to variables which bitbake doesn't know about as dependencies. E.g. if we expand a variable that calls a function that does a getvar on a dynamically produced variable name, and we forgot to add it to vardeps, *break*. It probably wouldn't even be that horribly difficult to pull off, though there'd be definite performance implications.
Apr 02 19:10:13 <realBigfoot> kergoth, i got a software that we are developing and the HEAD of the master repository is always changing, i'd like to see if there is a way to force do_fetch to make sure that we are getting the current code...
Apr 02 19:10:24 <kergoth> realBigfoot: set SRCREV = "${AUTOREV}" and call it a day
Apr 02 19:10:34 <kergoth> it'll follow the tip of the branch the url is set to
Apr 02 19:11:09 <kergoth> d = DictAccessWrapper(d, <vardeps of the current variable>) or so might work as a prototype
Apr 02 19:11:13 * kergoth ponders
Apr 02 19:11:39 <realBigfoot> kergoth, will ${AUTOREV} always verify if the repository has changed ?
Apr 02 19:11:55 <kergoth> if you add SRCPV to PV, then yes
Apr 02 19:12:10 <kergoth> it'll figure out the srcrev at parse time in that case, and fetch and all the rest will be rerun every time it changes
Apr 02 19:12:20 <realBigfoot> nice :)
Apr 02 19:12:26 <realBigfoot> how do I add SRCPV to PV?
Apr 02 19:12:39 <kergoth> grep the metadata for SRCPV and see some examples
Apr 02 19:12:48 <realBigfoot> thanks
Apr 02 19:12:59 <kergoth> it includes an autoincrementing number (to handle package upgrades) and the commit hash
Apr 02 19:13:21 <kergoth> each time srcrev changes, that number will get bumped
Apr 02 19:13:42 <realBigfoot> kergoth, this is nice
Apr 02 19:13:45 <realBigfoot> really nice
Apr 02 19:13:47 <realBigfoot> thanks
Apr 02 19:13:50 <kergoth> np
Apr 02 19:14:14 <kergoth> it's quite common to have one recipe that's locked down, and then a floating recipe that tracks the branch for devleopment, and set PREFERRED_VERSION when you want the floating one
Apr 02 19:23:29 <kergoth> and naturally i can't reproduce my sstate_dir + overrides problem..
Apr 02 19:24:05 <kergoth> or rather, i can, but not in a new isolated environment..
Apr 02 19:24:07 <kergoth> hmm
Apr 02 19:38:12 <nerdboy> what was the toaster init thing prior to a build again?
Apr 02 19:38:23 * nerdboy had not seen that before
Apr 02 20:08:56 <kergoth> Every time I think I've nailed this down, it turns out I'm wrong
Apr 02 20:08:59 <kergoth> I hate bugs like that
Apr 02 20:09:06 <kergoth> I think it may be a moving target :)
Apr 02 20:09:12 * kergoth sighs and keeps digging
Apr 02 20:24:52 * nerdboy puts $10 on kergoth 
Apr 02 20:25:19 <kergoth> ah, my initial thoughts may be correct, just i had remnant previous state between tests. i'd switch my config from working to brokena nd have it break, but switch back, and have it not start working again :)
Apr 02 20:33:42 <kergoth> okay, if i properly clear out *both* sstate_dirs (both the original and override value) between tests, it does look like it's the use of the override to define SSTATE_DIR is my problem. i think sstate_checkhashes or one of those is looking at the non-override sstate dir and making decisions based on that, but then the actual used sstate is the other, and the mismatch between the two can exhibit multiple behaviors depending on whether 1) it thinks its
Apr 02 20:33:43 <kergoth>  there but it isn't, or 2) it thinks it isn't there but it is. whew, i should have realized that. silly mistake in constructing the tests
Apr 02 20:34:24 <kergoth> then combine that with available sstate mirrors, and who knows when i'd get sstate used. it'd fetch sstates when it already had them, etc
Apr 02 20:34:44 * kergoth checks bitbake code to confirm the theory
Apr 02 20:51:08 <kergoth> er.. bitbake wrote siginfo for tasks of the non-native quilt, even though all i'm building is -c populate_sysroot quilt-native..
Apr 02 20:51:12 <kergoth> what the hell?
Apr 02 20:53:41 <kergoth> ah, it wrote fetch/unpack/patch siginfo for the target recipe even thoguh i wasn't building it, and didn't write out fetch/unpack/patch siginfo for the native recipe at all
Apr 02 20:53:56 <kergoth> that explains why i end up with so many builds where -S printdiff can't track down anything for fetch/unpack deltas..
Apr 02 20:57:19 <kergoth> so that's two bitbake bugs i found today.. one of those days, i guess :)
Apr 02 21:03:07 <bluelightning> kergoth: good catch(es)
Apr 02 21:03:20 <bluelightning> kergoth: it would be worth filing bugs, we're right on the edge of a release
Apr 02 21:03:45 <bluelightning> i.e. it sounds like it might be serious enough to delay it
Apr 02 21:03:56 <kergoth> confirmed, the runqueue is using self.cooker.data, not self.cooker.expanded_data, so it's not safe to use overrides with the sstate variables used by any of the sstate callbacks
Apr 02 21:04:24 <kergoth> not sure if anyone else cares about being able to use overrides with SSTATE_DIR and the other sstate variables, though ther eprobably is value in being able to _append to e.g. SSTATE_MIRRORS safely
Apr 02 21:04:48 <kergoth> the siginfo emission issue is definitely concerning, not having the info we need to diagnose an sstate reuse problem
Apr 02 21:04:49 <kergoth> hmm
Apr 02 21:15:48 * kergoth sets up a test case to see if this is the cause of his useless printdiffs
Apr 02 21:41:25 <kergoth> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7563 - for the curious. still digging
Apr 02 21:41:26 <yocti> Bug 7563: normal, Undecided, ---, richard.purdie, NEW , bitbake: printdiff looks for siginfo in incorrect locations for some tasks
Apr 02 21:42:01 <kergoth> seems sstatesig should be picking them up in the non-native paths, but isn't for some reason
Apr 02 22:21:16 * kergoth preps the fix and looks into the other issue
Apr 03 01:42:11 <chankit2> anyone knows what is manifest file in yocto?
Apr 03 02:14:16 <kergoth> "manifest file" is meaningless without context
Apr 03 02:18:44 <chankit2> kergoth: I can do better...how about manifest file for yocto image?
Apr 03 02:18:54 <chankit2> Is this a better context?
**** ENDING LOGGING AT Fri Apr 03 02:59:59 2015