**** BEGIN LOGGING AT Thu Dec 10 02:59:59 2015
Dec 10 07:15:27 <Ripmind> Hello. What do i need to change to get an uImage instead of zImage?
Dec 10 07:20:27 <AndersD> Ripmind, KERNEL_IMAGETYPE = "uImage" in the machine conf. Or KERNEL_IMAGETYPE_<machine> in local.conf
Dec 10 07:21:01 <Ripmind> Do i need to cleanall alfter that or is it enough to rebuild only the image i need?
Dec 10 07:23:26 <AndersD> It should be enough to just rebuild the image. You'll see that your kernel recipe will be rebuilt.
Dec 10 07:24:41 <Ripmind> Hmm.. I think i tried that already but it didn't rebuild anything. I will double-check it
Dec 10 07:25:22 <Ripmind> Or is it only the uboot.imx which i get? Not a .bin?
Dec 10 07:36:41 <AndersD> Well, if you don't ahve an old release, I'd assume that KERNEL_IMAGETYPE would be part of the signature... Otherwise, you could always try to rebuild the kernel manually, `bitbake virtual/kernel` after the change to see if you get a new build.
Dec 10 07:36:58 <AndersD> What you get from u-boot depends on your machine...
Dec 10 07:37:57 <Ripmind> Ok so the .imx file might be correct... I guess i need to research what this file is. Thank you :-)
Dec 10 07:38:24 <AndersD> But yes, fo imx, the suffix is imx (at least according to meta-fsl-arm).
Dec 10 07:38:34 <AndersD> https://github.com/Freescale/meta-fsl-arm/blob/master/conf/machine/include/imx-base.inc
Dec 10 07:39:10 <Ripmind> Now i just need to find out how to use this .imx.
Dec 10 08:12:14 <Ripmind> So much fun trying to get chromium runing as i want to...
Dec 10 08:12:32 <Ripmind> Only trying to fix it for over a month now
Dec 10 09:36:26 <gourve_l> Hi, can I create multiple packages (PACKAGES="${PN} ${PN}-demo") with a recipe wich inherit from setuptools? It seems that it is not possible
Dec 10 09:37:43 <gourve_l> because event with FILES_${PN}-demo += "${bindir}/demo.sh" I have a "QA Issue: Files/directories were installed but not shipped"
Dec 10 09:37:59 <gourve_l> s/event/even/
Dec 10 09:47:30 <styler2go> Does anyone know what u-boot.imx is for?
Dec 10 10:03:38 <t0mmy> styler2go: It is for Freescale iMX devices
Dec 10 10:04:23 <styler2go> Do i just use it as .bin file?
Dec 10 10:24:36 <olivier__> Hi everyone.
Dec 10 10:24:45 <olivier__> I'm in the process of patching a file from linux-mainline.
Dec 10 10:24:50 <olivier__> The file is found at 'build/tmp-glibc/sysroots/phyboard-mira-imx6-3/usr/src/kernel/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi'.
Dec 10 10:24:54 <olivier__> My first action was to create a patch then to create a "linux-mainline_%.bbappend" with a SRC_URI_append of my patch.
Dec 10 10:25:08 <olivier__> The issue I'm having is inside the patch file, since when I try to launch a 'bitbake my_image', I get the following error:
Dec 10 10:25:09 <olivier__>  "/usr/src/kernel/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi: No such file or directory"
Dec 10 10:25:17 <olivier__> The first line of the patch is the issue here; I don't know what path I should input.
Dec 10 10:25:18 <olivier__>  For now, it's "--- ../../../../../build/tmp-glibc/sysroots/phyboard-mira-imx6-3/usr/src/kernel/arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi".
Dec 10 10:25:23 <olivier__> I tried with only the "/usr/src/kernel/arch ..." but without success.
Dec 10 10:25:27 <olivier__> Does anyone knows what is the correct way to do it?
Dec 10 10:37:04 <clement_> olivier__: patches are applied to the recipe's source files located in the ${S} directory
Dec 10 10:38:10 <clement_> check what ${S} is pointed to and your patch has to start from there too, i thin
Dec 10 10:49:13 <olivier__> clement_: Hi, how can I display the ${D} variable ? I tried an 'echo' inside my .bbapend file, but the syntax isn't the correct one.
Dec 10 11:00:59 <olivier__> clement_: Ok, I found the path. I'm trying to correct it now. I'll keep you posted. Thanks.
Dec 10 11:07:53 <clement_> olivier__: nice good luck
Dec 10 11:10:27 <t0mmy> olivier__: You can used the command "bitbake -e linux-mainline" to print environment's variables, like ${S}...
Dec 10 11:12:27 <olivier__> t0mmy: And then grepping the result ?
Dec 10 11:36:46 <Noor1> olivier__: grep the result of redirect output  to any file and then open file to see values of variables
Dec 10 11:37:12 <Noor1> *grep the result or redirect
Dec 10 11:43:11 <caiortp>  /join #oe
Dec 10 11:43:37 <caiortp> sorry*
Dec 10 11:49:50 <rburton> otavio: the latest master run had some fetch errors, all appear to be in meta-fsl-*: http://errors.yoctoproject.org/Errors/Search/?items=10&query=5e3e2e0cbb0a49986f4653e64c4c8d2b5461645e
Dec 10 12:51:05 <olivier__> clement_: Hey again. I didn't succeed with my path
Dec 10 12:51:26 <olivier__> clement_: The part "+++ ..../my_file" seems to be the issue
Dec 10 12:51:38 <olivier__> clement_: "Command Error: exit status: 1  Output:"
Dec 10 12:51:55 <olivier__> clement_: " error: usr/src/kernel/arch/arm/boot/dts/imx6qdl-phytec-mira2.dtsi: No such file or directory"
Dec 10 12:52:32 <olivier__> clement_: Although the file can be found in path (from ${D})
Dec 10 12:52:36 <clement_> olivier__: ha yes, are you trying to patch the file in sysroot?
Dec 10 12:52:44 <olivier__> clement_: Any idea why it could fail?
Dec 10 12:55:18 <clement_> yes yocto works with source directory locate in tmp/work/<somedirectory>/linux-.../<version/WORKDIR/git
Dec 10 12:55:31 <clement_> so you have to patch there
Dec 10 12:55:45 <clement_> and after that it will copy your .dtsi in sysroot
Dec 10 12:57:25 <clement_> olivier__: see what i mean?
Dec 10 13:20:23 <olivier__> clement_: The file was found in '/build/tmp-glibc/work/phyboard_mira_imx6_3-phytec-linux-gnueabi/linux-mainline/3.19.5-phy6-r2.0/image/usr/src/kernel/arch/arm/boot/dts'
Dec 10 13:20:42 <olivier__> clement_: I'm not sure it's inside the "sysroot"
Dec 10 13:20:50 <olivier__> clement_: If that's what you're talking about
Dec 10 13:24:03 <clement_> can you give the result of ls in /build/tmp-glibc/work/phyboard_mira_imx6_3-phytec-linux-gnueabi/linux-mainline/3.19.5-phy6-r2.0/image/ ?
Dec 10 13:45:38 <olivier__> clement_: ls returns : boot   etc    lib     usr
Dec 10 13:46:23 <clement_> olivier__: sorry build/tmp-glibc/work/phyboard_mira_imx6_3-phytec-linux-gnueabi/linux-mainline/3.19.5-phy6-r2.0 this one?
Dec 10 13:52:40 <olivier__> clement_: Hey, I see my patch in this folder
Dec 10 13:53:26 <olivier__> clement_: and also another i created for kernel configuration (*.cfg)
Dec 10 13:55:02 <olivier__> clement_: Did you want to see all files/folders in this directory ?
Dec 10 14:07:14 <clement_> olivier__: it is normal to see your patch in this folder
Dec 10 14:07:27 <clement_> this is the working directory of your recipe
Dec 10 14:07:55 <clement_> and normally you have a directory with the source files
Dec 10 14:08:57 <olivier__> clement_: Maybe the 'git' folder
Dec 10 14:09:05 <clement_> yes this is the one
Dec 10 14:09:28 <clement_> and i think you can find your .dtsi in this folder
Dec 10 14:09:46 <olivier__> clement_: Yes, in the "git/arch/arm/boot/dts" folder
Dec 10 14:09:48 <clement_> and this is the folder yocto patches
Dec 10 14:10:23 <clement_> so if you do your patch from git i think it can work
Dec 10 14:11:32 <olivier__> clement_: "git format-patch -1 ?"
Dec 10 14:11:41 <clement_> yes
Dec 10 14:11:58 <olivier__> clement_: ok, I'll try
Dec 10 14:20:22 <olivier__> clement_: the operation 'do_patched' is completed, now it's 'do_package'
Dec 10 14:20:24 <olivier__> clement_:
Dec 10 14:20:32 <olivier__> clement_: It's seems to be working
Dec 10 14:20:42 <olivier__> clement_: Thanks a lot !
Dec 10 15:04:45 <clement_> olivier__: :)
Dec 10 15:16:25 <khem`> rburton: yt ?
Dec 10 15:16:44 <khem`> rburton: the musl branch you asked other day
Dec 10 15:17:12 <rburton> yeah was reviewing it on the train yesterday
Dec 10 15:17:25 <rburton> khem`: so what are the chances of being able to drop uclibc from oe-core too? :)
Dec 10 15:17:41 <khem`> https://github.com/kraj/openembedded-core/commits/kraj/musl
Dec 10 15:17:46 <khem`> rburton: 100%
Dec 10 15:17:58 <khem`> well, we can but
Dec 10 15:18:37 <khem`> some devs rejected to idea of moving it out atleast for 1 release
Dec 10 15:18:54 <rburton> yeah
Dec 10 15:19:00 <rburton> maybe after 2.1
Dec 10 15:19:02 <khem`> so in 2.1 my plan
Dec 10 15:19:15 <rburton> but this time we need musl stuff on the autobuilder
Dec 10 15:19:18 <khem`> is to get musl in and make it good enough
Dec 10 15:19:19 <rburton> what sort of images should work?
Dec 10 15:19:25 <rburton> presumaby sato isn't likely to work?
Dec 10 15:19:33 <khem`> sato works
Dec 10 15:19:35 <rburton> blimey!
Dec 10 15:19:51 <rburton> genuinely surprised about that
Dec 10 15:19:54 <khem`> but for first set I only posted patches wich make core-image-minimal
Dec 10 15:20:01 <rburton> yeah we can work up
Dec 10 15:20:03 <khem`> second set with have more
Dec 10 15:20:15 <khem`> I have world building
Dec 10 15:20:27 <khem`> minus 36 packages
Dec 10 15:21:40 <khem`> core-image-weston also works
Dec 10 15:22:06 <khem`> so phase 2 will have the needed patches for sato and weston
Dec 10 15:22:16 <khem`> image bullds
Dec 10 15:22:27 <rburton> nice
Dec 10 15:22:29 <rburton> thanks khem
Dec 10 15:22:30 <khem`> I also have gcc 5.3 upgrade lined up
Dec 10 15:22:45 <khem`> but that depends on gcc patch for musl
Dec 10 15:23:28 <khem`> see https://github.com/kraj/openembedded-core/commits/kraj/master
Dec 10 15:26:52 <khem`> musl patch for syslinux got merged today yay
Dec 10 17:01:16 <clement_> jlasnier: http://10.5.19.65:8080/psplash.service
Dec 10 17:12:41 <clement_> jlasnier:  http://10.5.19.65:8080/psplash_git.bbappend
Dec 10 17:20:29 <khem`> When sstate object is not found and build resorts to rebuilding the component it all goes fine but do_packagedata_setscene returns error and bitbake propagates that error too
Dec 10 17:20:36 <otavio> rburton: those are result of a fetchall test?
Dec 10 17:20:36 <khem`> has someone seen this ?
Dec 10 17:21:26 <khem`> ERROR: Fetcher failure: Unable to find file file://a2/sstate:sqlite3:mips32el-rdk-linux:3.8.3.1:r0:mips32el:3:a2000a30032418927177a8883b224125_packagedata.tgz anywhere. The paths that were searched were:
Dec 10 17:27:26 <JaMa> yes, I see this too recently
Dec 10 17:27:42 <JaMa> it was doing the same couple months ago, then I though it was fixed
Dec 10 17:27:56 <JaMa> but since last week I've seen it in couple builds again
Dec 10 17:27:59 <khem`> do you remember the fix ?
Dec 10 17:28:13 <JaMa> nope
Dec 10 17:28:25 <JaMa> and yesterday I've seen it in fido based build
Dec 10 17:28:39 <JaMa> not sure which release you're using
Dec 10 17:28:46 <khem`> I am on older release
Dec 10 17:28:50 <khem`> 1.6 based
Dec 10 18:25:36 <benjamirc> halstead: PM?
Dec 10 18:43:13 <tripzero> i should be able to create a bbappend for a foo-image.bb, right?
Dec 10 18:45:01 <deviosity> you should be able to for any bb file, I have always used require in a new bb image name so it was obvious it was custom.
Dec 10 18:45:59 <tripzero> deviosity: so you make a new foo-image.bb and then require the other?
Dec 10 18:46:08 <deviosity> i.e. custom-image-name.bb <- require recipes-core/images/core-image-base.bb
Dec 10 18:47:01 <deviosity> and then use CORE_IMAGE)EXTRA_INSTALL += " recipe1 recipe2"
Dec 10 18:47:13 <deviosity> CORE_IMAGE_EXTRA_INSTALLeven
Dec 10 18:47:38 <deviosity> I've always kept the originals the same, and use new names
Dec 10 18:48:01 <deviosity> but a .bbappend should work just fine
Dec 10 18:49:05 <deviosity> and then all you would need is the CORE_IMAGE_EXTRA_INSTALL lines with your additional recipes and any other customizations you need.
Dec 10 20:51:46 <adtec> Hi, I have a question pertaining to kernel development within Yocto.
Dec 10 20:51:51 <adtec> Would it be possible to use git revision control from within the Yocto build directory?
Dec 10 20:51:56 <adtec> The kernel is from my private remote repository.
Dec 10 20:52:01 <adtec> But is there a way to keep the original git remote origin after building the kernel?
Dec 10 20:52:05 <adtec> I am able to manually change the remote origin inside the build/tmp/work/... directory back to the repo, but I am looking for something more automatic.
Dec 10 20:53:46 <bluelightning> adtec: in 2.0 and later the remote origin is preserved automatically ; however rather than doing your changes in the work directory I would recommend using "devtool modify"
Dec 10 20:53:54 <bluelightning> that assumes you're using 2.0 though
Dec 10 20:54:56 <adtec> The BSP that I am using has not migrated to 2.0 yet, so for the moment I believe I am using 1.8
Dec 10 21:48:35 <rburton> otavio: yeah, probably (fetchall
Dec 10 22:06:31 <khem`> rburton: have you pulled
Dec 10 22:06:40 <khem`> musl branch into mut
Dec 10 22:06:51 <rburton> not yet
Dec 10 22:06:59 <rburton> why are you about to change it?
Dec 10 22:07:05 <rburton> because i was close
Dec 10 22:07:13 <khem`> no I am not
Dec 10 22:07:23 <khem`> I pushed a fix 2 days ago
Dec 10 22:07:29 <rburton> ok
Dec 10 22:07:41 <khem`> that was after I posted the patches
Dec 10 22:17:44 <rburton> khem`: okay musl in the next mut run
Dec 10 22:17:52 <khem`> cool
Dec 10 22:17:52 <rburton> (should be this evening assuming local testing works)
Dec 10 22:18:09 <khem`> I have done some world builds with glibc
Dec 10 22:18:14 <khem`> nothing seems to be broke
Dec 10 22:18:31 <khem`> I will prepare next set once its in
Dec 10 22:18:59 <khem`> I will also see if poky-tiny can use
Dec 10 22:19:03 <khem`> musl
Dec 10 22:19:11 <khem`> if there is interest
Dec 10 22:19:25 <khem`> that will free us from glibc/kconfig mess
Dec 10 22:19:27 <rburton> that would be good, imho
Dec 10 22:19:37 <rburton> yeah i can see why you're keen on that :)
Dec 10 22:19:37 <khem`> I agree
Dec 10 22:20:12 <khem`> anyway the minimal glibc becomes quite different that we very well might use musl
Dec 10 22:20:18 <khem`> or uclibc
Dec 10 22:20:22 <khem`> it wont matter much
Dec 10 22:33:19 <RP> khem`: is there no way to convince glibc that having some configuration is a good idea?
Dec 10 22:41:31 <khem`> RP: I tried but most of devs dont agree
Dec 10 22:41:51 <khem`> they say it adds additional variablity and test matrix
Dec 10 22:42:34 <khem`> so quality of testing with limited devs may deteriorate
Dec 10 22:44:22 <rburton> familiar argument ;)
Dec 10 22:45:25 <RP> khem`: its a shame. We could likely help with some of the testing...
Dec 10 22:47:48 <khem`> my opinion is also on same lines of other devs since every commit needs to be tested either complete system changes to use kconfig or nothing
Dec 10 22:48:03 <khem`> what we have currently is a retrofit
Dec 10 22:48:10 <khem`> and we will be in constant testing mode
Dec 10 22:48:22 <khem`> for every commit has a potential to break it
Dec 10 22:48:33 <khem`> and we can only tests few combos
Dec 10 22:49:03 <khem`> and we loose
Dec 10 22:51:46 <RP> khem`: or you slim down the set of options...
Dec 10 22:51:53 <RP> khem`: but I do understand the issue
Dec 10 22:54:13 <khem`> RP: poky-tiny's goal is small so musl can be a good option
Dec 10 22:56:45 <RP> khem`: right, it makes sense
Dec 10 23:24:44 <khem`> RP:  I think poky-tiny with musl will be quite well accepted
Dec 10 23:24:57 <khem`> for small footprint products
Dec 10 23:25:51 <khem`> openwrt is now using it as well
Dec 10 23:26:02 <khem`> and i am going to publish my meta-openwrt as well
**** ENDING LOGGING AT Fri Dec 11 02:59:58 2015