**** BEGIN LOGGING AT Tue Jan 19 02:59:58 2016
Jan 19 09:09:42 <mwarning> hi, how to I force a rebuild of the sdcard image?
Jan 19 09:36:46 <frsc> mwarning: I guess this should work: bitbake <image> -c rootfs -f
Jan 19 09:38:03 <kalyan> Hi yocto team
Jan 19 09:38:29 <kalyan> i am facing issue in creating sdimage for raspberrypi on poky
Jan 19 09:39:05 <kalyan> error it is showing is do_image_rpi-sdimg: not found
Jan 19 09:42:10 <kalyan> @khem: any idea on this issue
Jan 19 09:48:07 <joshuagl> using the master branch? there was a patch submitted recently to fix that
Jan 19 10:16:50 <jaz303> hello
Jan 19 10:17:40 <jaz303> i've installed meta-toolchain-qt5 but i'm unable to compile programs that use webkit
Jan 19 10:18:56 <jaz303> i think i need to update PACKAGECONFIG in some way
Jan 19 11:13:16 <CTtpollard> Hi, is it possible to have two git uri in a recipe, as such that the second one is fetched and unpacked into the same work dir as the first?
Jan 19 11:15:11 <bluelightning> CTtpollard: yes, you just need to set destdir= on one or both of them; also specify name= on both and then you can set SRCREV separately for each one
Jan 19 11:16:06 <CTtpollard> bluelightning: are you aware of any examples of this that I could look at?
Jan 19 11:16:21 <bluelightning> just looking for that now
Jan 19 11:17:16 <CTtpollard> thanks :) I have a source that keeps its plugins in a separate repo, and needs to be present at compile time
Jan 19 11:17:45 <bluelightning> sorry, I meant to say destsuffix=
Jan 19 11:18:09 <bluelightning> meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_git.bb would be one example
Jan 19 11:18:12 <rburton> if there's any gstreamer git recipes
Jan 19 11:18:15 <rburton> oh yeah, there you go :)
Jan 19 11:18:18 <bluelightning> ;)
Jan 19 11:19:42 <CTtpollard> cheers :)
Jan 19 11:29:04 <jaeckel> does someone of you know of a good tutorial about how to work with the devshell?
Jan 19 11:32:39 <jaeckel> it should e.g. also cover how to package a modified recipe
Jan 19 11:35:16 <jaeckel> or is it just bitbake -c devshell recipe -> bitbake -c build recipe ?
Jan 19 11:51:47 <bluelightning> jaeckel: if you're looking at modifying the source for a recipe and you're using 2.0+ I'd highly recommend looking at devtool - in particular devtool modify
Jan 19 11:52:41 <bluelightning> unfortunately I have to get some sleep, but there are basic docs here: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-devtool-in-your-workflow
Jan 19 11:53:00 <jaeckel> cool! thanks a lot
Jan 19 11:53:02 <jaeckel> and sleep well
Jan 19 11:54:20 <bluelightning> np
Jan 19 11:54:22 <bluelightning> thanks
Jan 19 12:02:39 <jaeckel> are there any efforts in creating&maintaining auto-completion scripts for bitbake and devtool?
Jan 19 12:41:44 <Crofton|work> belen, any pointers at getting toaster to work with an existing OE setup?
Jan 19 12:43:29 <belen> Crofton|work: have you emailed your set up to townxelliot?
Jan 19 12:43:39 <Crofton|work> no
Jan 19 12:43:43 <Crofton|work> I suppose I should
Jan 19 12:44:04 <Crofton|work> I got past the template file problem
Jan 19 12:44:32 <Crofton|work> and got the web interface started, but it didn't seem aware I alrady had a conf/bblayers
Jan 19 12:45:18 <Crofton|work> I'm leaving for Berlin Saturday (weather willing)
Jan 19 12:45:31 <Crofton|work> I ahve the monnow and the E310 running (very closely) the same image
Jan 19 12:45:56 <belen> Crofton|work: we would need to understand how you are set up. It is very possible that there are some assumptions built in regarding location of certain files
Jan 19 12:45:59 <Crofton|work> just missing toaster data to show with them
Jan 19 12:46:13 <Crofton|work> yeah, I'll reply to the email you sent
Jan 19 12:46:57 <belen> Crofton|work: I will be in Brussels Friday early afternoon. Worst case scenario we can try to built it together Friday or Saturday
Jan 19 12:47:43 <Crofton|work> ok, I am in around 2PM staying in an airbnb across from St Nicks
Jan 19 13:47:05 <bmg> Hi, I am having a problem when building 'xen-image-minimal'
Jan 19 13:47:19 <bmg> "ERROR: QA Issue: xen: Files/directories were installed but not shipped in any package:
Jan 19 13:47:22 <bmg>   /etc/init.d/xendriverdomain"
Jan 19 13:47:41 <zeddii> bmg. there's a patch on the meta-virtualization list for that. it arrived about 15 minutes ago.
Jan 19 13:47:58 <bmg> zeddii: thank you !
Jan 19 13:48:27 <zeddii> I'm merging it right now. so if you pull in about 5 mins, it'll be there.
Jan 19 13:58:56 <ryansturmer> If I write my own do_fetch and do_unpack - I suppose I have to write my own do_cleanall state to make sure my downloaded stuff gets trashed?
Jan 19 14:00:36 <ryansturmer> ,and if I write my own do_cleanall, do I have to clean the shared state cache myself as well?
Jan 19 14:00:50 <ryansturmer> (Since I'm overriding that default behavior)
Jan 19 14:04:06 <ryansturmer> (Or is the thing to do to override do_clean, and leave cleanstate and cleanall as is
Jan 19 14:33:30 <Spulit> Hi, I was trying to create a core image (valleyisland-64) using the meta-intel layer. I properly configured bblayers.conf and local.conf but bitbake returns an error saying that MACHINE name is not valid... any idea?
Jan 19 14:37:08 <bmg> zeddii: thanks, pulled and build further, but when finishing off do_rootfs I get the following error:
Jan 19 14:37:12 <bmg> http://pastebin.com/gL9LeRqX
Jan 19 14:41:11 <zeddii> bmg. so some kernel modules didn't get built, are you using a custom kernel, or linux-yocto directly ?
Jan 19 14:44:04 <bmg> zeddii: just using the yocto kernel unmodified
Jan 19 14:44:38 <bmg> I have not cloned it specifically, as I assumed that I was not modifying
Jan 19 14:44:54 <zeddii> hmm. so those should be present. this is all with up to date master branches (for everything) ?
Jan 19 14:46:29 <bmg> http://pastebin.com/9Wqd8Y0u
Jan 19 14:46:41 <bmg> are the steps that I have taken
Jan 19 14:47:04 <bmg> cloned most of the code yesterday, and just pulled the meta-virtualization patch that you made this afternoon
Jan 19 14:47:19 <bmg> so *should* be upto date
Jan 19 14:54:21 <CTtpollard> Spulit: does bitbake-layers show-layers list meta-intel?
Jan 19 14:54:33 <zeddii> bmg. hah. It would have built the 4.4 kernel if you used master, but xen only has a 4.1 configuration. I can clone the 4.1 config, to 4.4 and push it. but obviously that won't be tested.
Jan 19 14:54:37 <zeddii> bmg. pushed.
Jan 19 14:58:05 <bmg> captain guinea pig at your service :)
Jan 19 14:59:03 <bmg> thank you, so I should stick to the fido branch to have a good config ?
Jan 19 14:59:41 <zeddii> bmg. I'm not using the configs directly at the moment, so I can't say if fido was any better. I know people are using master, so that's where I'd suggest at the moment.
Jan 19 15:00:08 <zeddii> you can always set a PREFERRED_VERSION for linux-yocto to 4.1, and that would use the 4.1 kernel and that tested set of configs.
Jan 19 15:21:22 <Spulit> CTtpollard: Well, it seems not... I added it in bblayers.conf...maybe something's missing...
Jan 19 15:22:52 <Spulit> CTtpollard: or better...it shows the meta-intel layer, but not the meta-valleyisland...
Jan 19 15:24:00 <CTtpollard> Spulit: add a direct path to the meta-valleyisland in bbylayers and try again
Jan 19 15:26:21 <rburton> khem: good news: the musl branch appears to build fine :)
Jan 19 15:26:53 <khem`> phew
Jan 19 15:27:09 <khem`> I am now on my way to build an XFCE image
Jan 19 15:27:09 <rburton> :)
Jan 19 15:27:15 <khem`> that I will install on my desktop
Jan 19 15:27:31 <khem`> and eat my own dogfood
Jan 19 15:28:09 <rburton> nice
Jan 19 15:41:13 <Spulit> CTtpollard: That's what I did... but it seems it is not recognising it...weird...
Jan 19 15:45:50 <Spulit> CTtpollard: I even added it using bitbake-layers add-layer
Jan 19 15:46:28 <CTtpollard> Spulit: what commit sha is this off meta-intel? master?
Jan 19 15:46:31 <CTtpollard> *of
Jan 19 15:52:53 <Crofton|work> belen, https://plus.google.com/101203797379542776446/posts/QxWKnqStumc
Jan 19 15:53:04 <Spulit> CTtpollard: yes, I recently did a git clone
Jan 19 15:53:56 <belen> Crofton|work: nice
Jan 19 15:54:18 <Crofton|work> just so you know this isn't an academic exercise :)
Jan 19 15:54:30 <rburton> Crofton|work: you mean you do work?!
Jan 19 15:54:39 <Crofton|work> sometimes
Jan 19 15:55:14 <belen> Crofton|work: I like academic exercises, but whatever ;)
Jan 19 15:55:20 <Crofton|work> heh
Jan 19 15:55:52 <Crofton|work> always good to remind people that there are real world applications for this work :)
Jan 19 15:56:30 <Crofton|work> life is more than autobulder reports and bug stats
Jan 19 15:58:04 <CTtpollard> Spulit: what exactly have you put as the machine name in local.conf?
Jan 19 16:02:37 <Spulit> CTtpollard: valleyisland-64
Jan 19 16:33:50 <khem> rburton:
Jan 19 16:34:20 <khem> there are couple of more patches unrelated to  musl
Jan 19 16:34:40 <khem> that I will submit later this week
Jan 19 17:51:15 <bluelightning> zeddii: JaMa points out that linux-yocto-4.4.git is nearly 2x the size of linux-yocto-4.1.git; is that expected?
Jan 19 17:53:28 <zeddii> hmm. no. not at all.
Jan 19 17:53:46 <JaMa> zeddii: and as bluelightning mention this topic, why do you need separate repository for each version? unlike other kernel repositories?
Jan 19 17:54:12 <JaMa> http://pastebin.com/sqSbxMfS
Jan 19 17:54:38 <zeddii> because the patches are rebsed.
Jan 19 17:54:50 <zeddii> same reason why Greg's -stable, and the -rt aren't in the same tree.
Jan 19 17:55:21 <JaMa> isn't it enough to rebase them in different branches?
Jan 19 17:55:32 <JaMa> while reusing majority of objects between all versions?
Jan 19 17:55:35 <zeddii> you'd end up with a huge spew of branches.
Jan 19 17:55:43 <zeddii> I could also archive old versions of the tree.
Jan 19 17:55:53 <JaMa> now you have huge sped of branches in spew of repositories
Jan 19 17:56:01 <zeddii> shrugs
Jan 19 17:56:12 <zeddii> I can keep one master version of tree and rebase it.
Jan 19 17:56:20 <zeddii> and we shuffle old ones off. that'll work as well.
Jan 19 18:00:35 * armpit kernel maint is a lot of work.. is for what ever makes sense
Jan 19 18:01:40 <zeddii> I'm seeing a slightly larger tree on my development box.  Is there a way to trigger a server-side git-gc, or do I need halstead for that ?
Jan 19 18:02:37 <halstead> zeddii: are you referring to contrib?
Jan 19 18:03:19 <zeddii> linux-yocto-4.4 itself. it's no different than other kernel trees. I'm not sure why it is coming in as 2x the 4.1 tree.
Jan 19 18:03:37 <khem`> halstead: we need to delete user branches which has been merged
Jan 19 18:03:44 <khem`> from contrib trees
Jan 19 18:04:24 <khem`> halstead: may be you should send a notification to mailing list to remind users to delete dead branches
Jan 19 18:04:29 <halstead> zeddii: I ran gc and prune when I set up 4.4. I can rerun with --aggressive
Jan 19 18:04:41 <zeddii> ok. so it shouldn't be that then.
Jan 19 18:04:46 <khem`> zeddii: did you see JaMa 's message on OE channel ?
Jan 19 18:04:55 <zeddii> nope. not on the oe channel.
Jan 19 18:04:59 <khem`> zeddii: 4.4 repo is quite big
Jan 19 18:05:05 <zeddii> that's what we are discussing :)
Jan 19 18:05:11 <armpit> more features ; )
Jan 19 18:05:15 <zeddii> trying to figure out what it is. mine is showing about the same size.
Jan 19 18:05:20 <halstead> khem`: will do. I also will move old branches to archive.
Jan 19 18:05:23 <khem`>  JaMa	wondering why it's twice as big as other linux-yocto repos
Jan 19 18:05:24 <khem`> [09:44:58]  <JaMa>	986964  /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-3.19.git
Jan 19 18:05:24 <khem`> [09:44:58]  <JaMa>	1022940 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-4.1.git
Jan 19 18:05:24 <khem`> [09:44:58]  <JaMa>	1269560 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-dev.git
Jan 19 18:05:26 <khem`> [09:44:58]  <JaMa>	2382760 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-4.4.git
Jan 19 18:05:45 <JaMa> khem`: complete list is in pastebin couple lines above
Jan 19 18:06:37 <khem`> JaMa: I just joined here client doesnt have much history
Jan 19 18:06:48 <JaMa> it could be some git fetcher screw-up, because it was also taking forever to fetch (cca 20 hours on my 200Mbit/s line)
Jan 19 18:06:59 <khem`> halstead: I would prefer for folks to delete the dead branches before you archive them
Jan 19 18:06:59 <zeddii> interesting. my downloads shows 4.4 as slightly smaller.
Jan 19 18:07:00 <zeddii> argh
Jan 19 18:07:08 <zeddii> yow-bashfiel-d4 [/home/bruc...loads/git2]> du -sh git.yoctoproject.org.linux-yocto-4.4.git/
Jan 19 18:07:09 <zeddii> 1.1G    git.yoctoproject.org.linux-yocto-4.4.git/
Jan 19 18:07:09 <zeddii> yow-bashfiel-d4 [/home/bruc...loads/git2]> du -sh git.yoctoproject.org.linux-yocto-4.1.git
Jan 19 18:07:09 <zeddii> 1.2G    git.yoctoproject.org.linux-yocto-4.1.git
Jan 19 18:07:19 * zeddii should pastebin that. sorry.
Jan 19 18:07:32 <zeddii> 1G of junk. grr.
Jan 19 18:07:42 <khem`> pastebin removes the links after a while
Jan 19 18:08:02 <khem`> and irc logs loose vital info when referred to in future
Jan 19 18:08:19 <khem`> 2-5 lines should be fine to paste
Jan 19 18:08:33 * zeddii nods.
Jan 19 18:09:03 <zeddii> anyway. will figure out what is going on. definitely not on purpose.
Jan 19 18:09:08 <khem`> just dont paste gcc -E output here when I ask for one :)
Jan 19 18:09:12 <zeddii> heh
Jan 19 18:09:20 * zeddii puts that on his TODO list!
Jan 19 18:09:59 <khem`> zeddii: btw. what all ppc machines support is good in kernel
Jan 19 18:10:11 <JaMa> it looks like fetcher fault, see http://pastebin.com/wG0LiVhb there is couple big git.yoctoproject.org.linux-yocto-4.4.git/objects/pack/tmp_pack_* files which weren't in earlier versions
Jan 19 18:10:33 <zeddii> khem. that's a small list. a dying breed to be sure.
Jan 19 18:10:49 <zeddii> khem': and you are thinking in terms of qemu system emulation
Jan 19 18:10:49 <khem`> halstead: what git version do you run on git yp org
Jan 19 18:11:02 <khem`> zeddii: yes
Jan 19 18:11:08 <zeddii> I saw your email about the instruction set to the oe-architecture list.
Jan 19 18:11:20 <halstead> I think 1.8.4. I'll need to verify
Jan 19 18:11:33 <khem`> halstead: hmm may be upgrade to 2.x
Jan 19 18:11:35 <zeddii> there were rumours of a system emulated FSL machine, but I've never seen it work. all of the modern machines need ppc KVM to fill in the gaps.
Jan 19 18:12:00 <khem`> halstead: if you run ubuntu on those boxes then they have a separate feed repo for git
Jan 19 18:12:17 <khem`> zeddii: I am not sure if fsl would care any more
Jan 19 18:12:29 <khem`> there n/w chips are moving away from ppc
Jan 19 18:13:39 <khem`> halstead: gerrit exposed some issues in garbage collection IIRC
Jan 19 18:14:11 <halstead> Do you have a link?
Jan 19 18:17:55 <JaMa> halstead: any progres with oe-commits ML?
Jan 19 18:19:09 <halstead> No. I did see your error which is helpful. Can I make a testing branch to do repeated tests on if I delete it after?
Jan 19 18:44:50 <fsdun> JaMa, still using SHR disk for builds?
Jan 19 18:51:31 <JaMa> fsdun: "disk"? I'm still using SHR distro for some builds
Jan 19 18:51:54 <halstead> khem`, Updated to 2.3.7 for now and doing some tests. We are using 1.8.3 everywhere else though. If anything odd happens that's what we will revert to.
Jan 19 18:52:10 <fsdun> I have seen /media/shr in your pastebin
Jan 19 18:52:43 <JaMa> fsdun: that's shr-chroot partition (minimalistic Gentoo chroot)
Jan 19 18:53:14 <JaMa> http://git.shr-project.org/git/?p=shr-chroot.git;a=summary is still being updated
Jan 19 18:53:24 <fsdun> ok :)
Jan 19 18:55:41 <fsdun> any updates on SHR itself?
Jan 19 19:02:38 <halstead> zeddii, linux-yocto-4.4 is now 894M. Does that sound right?
Jan 19 19:02:46 <zeddii> yep
Jan 19 19:03:18 <JaMa> fsdun: I'm just keeping it building and upgrading stuff used elsewhere (like efl)
Jan 19 19:03:38 <JaMa> fsdun: Bob recently started working on porting it to Galaxy
Jan 19 19:04:35 <JaMa> fsdun: but I spent very little time on SHR specific stuff nowadays, meta-oe, LuneOS, WebOS taking most of my free time
Jan 19 19:05:43 <fsdun> oh. WebOS is still WIP?
Jan 19 19:06:26 <fsdun> I cannot build it at home. I'm quite lazy these days when I'm at home
Jan 19 19:06:49 <fsdun> (my laptop is still 32-Bit based)
Jan 19 19:06:51 <JaMa> the opensource part is alive only in LuneOS, but there is a lot of WebOS work inside LG
Jan 19 19:06:57 <fsdun> so I cannot build webkit :P
Jan 19 19:35:19 <fsdun> JaMa, is morphis still active for luneos?
Jan 19 19:37:54 <JaMa> fsdun: also busy with other projects, so only a bit
Jan 19 19:38:25 <fsdun> hmpf. DISK_SIGNATURE_GENERATED adds random bits to the signature of bootdirectdisk
Jan 19 19:41:11 <fsdun> JaMa, I have some nice HW at work, so I don't do much at home
Jan 19 19:41:50 <fsdun> I started a telepathy plugin for whispersystems, but it's already sleeping :(
Jan 19 19:41:59 <JaMa> is it the cause for: ERROR: Bitbake's cached basehash does not match the one we just generated (/home/jenkins/oe/world/shr-core/meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-klibc-image.bb.do_image_cpio)!
Jan 19 19:42:05 <JaMa> ERROR: The mismatched hashes were 7a4f4526036cf9bf551cab58e875b1f8 and 6aa63fdc98b3cd1705cd4..
Jan 19 19:42:24 <fsdun> maybe
Jan 19 19:42:40 <fsdun> it generates a uuid
Jan 19 19:43:41 <fsdun> maybe DISK_SIGNATUREDISK_SIGNATURE[vardeps-exclude] += "DISK_SIGNATURE_GENERATED" is required?
Jan 19 19:46:00 <fsdun> JaMa, you can check by using bitbake -S printdiff <target> after building
Jan 19 19:47:00 <JaMa> fsdun: I know
Jan 19 19:47:07 <fsdun> ok ;)
Jan 19 19:49:47 <JaMa> it got broken someday after 21151114 when we had clean report: http://lists.openembedded.org/pipermail/openembedded-devel/2015-November/104638.html
Jan 19 20:02:24 <fsdun> have to leave
Jan 19 20:02:26 <fsdun> good night
Jan 19 20:04:20 <nerdboy> otavio: ??
Jan 19 20:04:47 <nerdboy> is there a linux-fslc-4.x commit that fixes this?  https://github.com/SolidRun/linux-imx6/commit/ab77dfaaabea44c831820cda38b386510d7e9aa9
Jan 19 20:05:26 <nerdboy> i get no wifi at all on cubox-i with 4.4 kernel
Jan 19 20:05:40 <nerdboy> works fine on wand/udoo
Jan 19 20:16:21 <saisoj> Hi guys, is there a way of modifying u-boot config without actually forking it? e.g. through a .bbapend or something, similar to how I change the kernel configuration.
Jan 19 22:04:48 <tripzero2> is there a variable for i586 vs i686?  ${ARCH}?
Jan 19 22:06:11 <bluelightning> tripzero2: TARGET_ARCH I would think
Jan 19 22:06:25 <tripzero2> kk, will try
Jan 19 22:06:26 <bluelightning> tripzero2: you can use an override for that
Jan 19 22:06:42 <bluelightning> e.g.
Jan 19 22:06:43 <bluelightning> VARNAME_i586 = "the value for i586"
Jan 19 22:06:46 <bluelightning> VARNAME_i686 = "the value for i586"
Jan 19 22:06:49 <bluelightning> er
Jan 19 22:06:55 <bluelightning> VARNAME_i686 = "the value for i686"
Jan 19 22:07:29 <tripzero2> bluelightning: what about VARNAME_${TARGET_ARCH} = "blah" ?
Jan 19 22:08:02 <bluelightning> that's not going to help - that's equivalent to VARNAME = "blah"
Jan 19 22:08:24 <bluelightning> the override means "only apply this assignment if the specified override is in OVERRIDES"
Jan 19 22:08:56 <bluelightning> and ${TARGET_ARCH} is in the value of OVERRIDES
Jan 19 22:09:09 <bluelightning> well, actually ${TRANSLATED_TARGET_ARCH}
Jan 19 22:09:31 <bluelightning> (which is TARGET_ARCH with underscores converted to hyphens)
Jan 19 22:10:23 <bluelightning> thus you really want VARNAME_override = "desired value if override applies"
Jan 19 22:10:38 <tripzero2> i think i understand
Jan 19 22:11:02 <tripzero2> VARNAME_${TARGET_ARCH} wouldn't make for a very good arch-specific override :P
Jan 19 22:11:14 <bluelightning> not really no, it'd always apply :)
Jan 19 22:27:58 <nerdboy> otavio: there are a few things missing from the cubox-i device tree config
Jan 19 22:28:25 <nerdboy> not that i know exactly how to shoehorn them in...
Jan 19 22:29:11 <nerdboy> but they *are* defined in wandboard and udoo .dtsi files
Jan 19 23:12:58 <Eric____> i m trying to run this command and getting some framebuffer issue can anyone help
Jan 19 23:12:59 <Eric____> gst-launch-1.0 imxv4l2src device=/dev/video0 ! imxipuvideotransform ! imxipuvideosink framebuffer=/dev/fb1
Jan 19 23:13:15 <Eric____> Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. ERROR: from element /GstPipeline:pipeline0/GstImxIpuVideoSink:imxipuvideosink0: could not open /dev/fb1: No such device or address Additional debug info: ../src/common/blitter_video_sink.c(743): gst_imx_blitter_video_sink_open_framebuffer_device (): /GstPipeline:pipeline0/GstImxIpuVideoSink:imxipuvideosink0 Setting pipeline to NULL ... Freeing pipeline .
Jan 19 23:14:27 <Eric____> http://pastebin.com/JRbssTGT
Jan 19 23:15:26 <Eric____> @DarkNight, can yoy please help
Jan 19 23:17:52 <Eric____> have anyone seen this issue?
Jan 19 23:59:33 <Eric____> can anyone help on this?
Jan 19 23:59:43 <Eric____> see pastebin for error
Jan 19 23:59:44 <Eric____> http://pastebin.com/JRbssTGT
Jan 20 00:24:14 <khem> Eric____: do you have the relevant device created by fb driver ?
Jan 20 00:24:30 <khem> bluelightning: btw. another thing with devtool
Jan 20 00:24:46 <khem> bluelightning: when I build one package for one machine and then switch machine
Jan 20 00:25:02 <khem> it gets into issues
Jan 20 00:25:33 <khem> since it tries to reuse the old .o files from this component since its under devtool workflow
Jan 20 00:25:50 <khem> no clean helps
Jan 20 00:26:23 <khem> I have to go into the externalsrc sources of the component
Jan 20 00:26:23 <kergoth> that seems strange, externalsrc defaults to using a separate B from S, so B would just be wiped, no?
Jan 20 00:26:29 <khem> and manually run make clean
Jan 20 00:26:49 <khem> kergoth: in this case B = S
Jan 20 00:27:03 <khem> since its a broken autotools
Jan 20 00:27:43 <kergoth> doesn't autotools.bbclass auto-run make clean in that case? i thought it did
Jan 20 00:27:55 <khem> but same will happen with non autotooled packages
Jan 20 00:28:03 <kergoth> yeah, autotools_preconfigure has code specifically to handle it
Jan 20 00:28:13 <khem> doesnt kick in
Jan 20 00:28:40 <khem> may be its due to externalsrc confusion
Jan 20 00:28:50 <khem> since now the B = externalsrc locaiton of S
Jan 20 00:29:37 <khem> not sure whats happening since I am more focussed on fixing the package to build then the infra
Jan 20 00:29:40 <khem> for this case
Jan 20 00:29:51 <khem> the package fbset shows same problem
Jan 20 00:30:03 <kergoth> sounds like this doesnt' have anything to do with devtol or its workflow and is just a bug in use of externalsrc without B
Jan 20 00:30:07 <kergoth> open a bug
Jan 20 00:30:26 <khem> yes will do
Jan 20 00:30:58 <kergoth> whew, think I finally got my auto relocating sdk bits working for those who don't use shar. just saves the relocated path into a file and uses that for the next relocation if it gets moved, and checks that on every source of the env setup script
Jan 20 00:31:00 <khem> I think devtool just is utilizing the underneath facilities so you are right
Jan 20 00:40:30 <khem> filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=8950
Jan 20 00:40:31 <yocti> Bug 8950: normal, Undecided, ---, richard.purdie, NEW , Clean operation not done with externalsrc when S = B
Jan 20 01:12:03 <bluelightning> khem: I'd anticipated problems changing machine in the case of machine-specific patches but I hadn't thought of this kind of issue
**** ENDING LOGGING AT Wed Jan 20 02:59:59 2016