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