**** BEGIN LOGGING AT Fri Jul 21 03:00:02 2017 Jul 21 10:58:30 hey Jul 21 11:00:37 i have an issue with gcc in the pyro release, for which I need to apply a patch. If I just fork the package it's as easy as adding the patch to the backports section in gcc-6.3.inc ... now I'm wondering how to properly do this. Creating bbappend files for all the packages build by gcc seems pretty cumbersome and error prone (also just trying to add the patch to the packages where it's actually needed seems error prone) Jul 21 11:01:02 is there a way to append to BACKPORTS from the gcc-6.3.inc file? Jul 21 11:06:30 or different approach: would it be desired to upstream my patch? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236 Jul 21 11:20:33 domme: yes put it in backports section and apply to master Jul 21 11:20:38 then backport to pyro Jul 21 11:22:04 khem: oh right, i thought it was irrelevant to master because master already has GCC-7, but of course you can also use older GCCs including 6.3 Jul 21 11:24:09 khem: so I probably need to follow this procedure: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#A_task-oriented_guide_to_creating_a_patch for master Jul 21 11:24:28 khem: then when it's ack'ed/merged for master I can backport it to pyro? Jul 21 11:24:31 Still around RP ? Can you chime in on if we should get rid of "vmdk" as a target? Thanks! Jul 21 11:25:31 Tartarus: I'm around. Chime in where? Jul 21 11:26:27 openembedded-core Jul 21 11:26:39 starts at [PATCH 1/2] image-vm: Convert vmdk/vdi/qcow2/hdddirect images to IMAGE_CMD Jul 21 11:28:23 Tartarus: hmm, good question. I guess it comes down to whether vmdk is useful in its own right? Jul 21 11:29:06 RP: I think it is. Over in AGL land we spit out various images as vmdk so that people can use them in qemu/vmware player/virtualbox Jul 21 11:29:22 Which is what got me started here, they're big so we'd like to spit them out compressed, from the get-go Jul 21 11:29:54 (And then, since we might have IDE or SATA for rootfs, use PARTUUID rather than root=/dev/xxa2 be encoded in the image) Jul 21 11:30:08 afk, time to take the kids to school, groceries Jul 21 11:31:17 Tartarus: I think your patches look good, just a question of whether there are more changes that make sense. I'm not 100% sure what I'm being asked... Jul 21 11:31:57 Tartarus: pohly is around over in in #yocto fwiw (he may also be at lunch right now) Jul 21 11:46:42 domme: yes Jul 21 12:36:19 khem, my my, I have to transplant piggy.o and not decompress.o too boot ... Jul 21 12:38:01 (the sdk finally built btw, no probs with binutils) Jul 21 12:57:15 ant_work: did it work when you use piggy.o from 6.0 Jul 21 12:58:45 tig Jul 21 13:05:49 khem, not with only piggy.o Jul 21 13:06:15 JaMa: just confirmed you're right about the prserv slowing down builds so you see those retries Jul 21 13:06:20 ofc with misc.o lib1funcs.o string.o and decompress.o .. practically the old kernel :) Jul 21 13:08:30 RP: back. pohly wants things taken in a different direction, which I'm not convinced is right Jul 21 13:10:35 Tartarus: I can see things both ways to be honest Jul 21 13:11:02 Tartarus: these image types are kind of like "compression" operations in that they encapsulate other formats Jul 21 13:11:20 RP: good :) Jul 21 13:11:41 RP, yeah. And it seems like we have a few distinct ways to say "lets generate a raw disk image" Jul 21 13:12:23 Tartarus: right. I have been hoping we might just need wic eventually and we can take this out of the metadata a bit Jul 21 13:44:55 Is this the correct place to ask question on writing layers/recipes? Jul 21 13:51:17 Chocobo: certainly Jul 21 13:54:03 bluelightning, thanks. So I am new (switching from buildroot) and I have a layer (meta-xilinx) that creates a devicetree file with a horrific name. Is it possible to create another layer that renames that file in kernel-devicetree package to something more reasonable? would that be a good candidate for a .bbappend file? Jul 21 13:57:39 Chocobo: that should be fairly easy to do through a bbappend yes Jul 21 14:05:04 bluelightning, thanks. I will give it a shot. Jul 21 14:11:49 hi Jul 21 14:12:05 CXXFLAGS := "${@oe_filter_out('-fvisibility-inlines-hidden', '${CXXFLAGS}', d)}" Jul 21 14:12:21 is this the right way to do what it looks like itis doing Jul 21 14:12:52 you could use CXXFLAGS_remove = "-fvisibility-inlines-hidden" Jul 21 14:12:55 now a days Jul 21 14:13:16 nowadays is like what? this project is using a quite dated build Jul 21 14:20:33 I dont know what you are using, _remove qualifier is couple of years old Jul 21 14:21:04 heeen: _remove was introduced in dora I believe, which was indeed some time ago Jul 21 14:21:32 ok. then if you are not older than dora then use it Jul 21 14:22:07 it seems I have been forever doing OE Jul 21 14:22:24 not forever.. there was a time before OE I remember.. ;) Jul 21 14:22:47 ah yes you are right the baptism as MV Jul 21 14:23:08 s/as/at Jul 21 14:24:45 how long were you at MV? 2-3 years or so? Jul 21 14:25:01 4 Jul 21 14:25:25 * fray was there May 2000 to Jan 2006 Jul 21 14:25:57 yeah me until 04-08 Jul 21 14:26:24 Ahh I thought you'd left around 2007-ish Jul 21 14:41:30 it was 7ish, Jan 08 Jul 21 15:12:09 Hmm, would really be nice to make wic handle fixed size disk images better, for read-only-rootfs. I.e. set a fixed size for the image and allow the ability to specify which partition will grow to consume the unused space Jul 21 15:12:13 thoughts? Jul 21 15:12:46 would be particularly useful for growing an added user data partition, for non-volatile storage of the writable areas Jul 21 15:14:41 course could always grow it to size on first boot, but not always viable Jul 21 15:14:42 hmm Jul 21 15:17:22 Actually, can address this via the resize helper, just configure it to resize a user data or home partition rather than the rootfs, when it's read-only-rootfs Jul 21 17:25:59 So I have what should be a VERY simple bbappend file called "device-tree%.bbappend. It shows up in "bitbake-layers show-appends" but it doesn't seem to do anything. I am trying to append to IMAGE_POSTPROCESS_COMMAND: https://justpaste.it/1979y Jul 21 17:26:10 Any idea what might be going wrong? Jul 21 17:28:02 IMAGE_POSTPROCESS_COMMAND Is run at image creation time by image.bbclass in *image recipes* Jul 21 17:28:13 if that recipe isn't an image, it won't do anything Jul 21 17:28:29 if it is, then use bitbake -e to verify that the variable is set to what you think it is, and wasn't overridden by something else Jul 21 17:28:51 Ah, I didn Jul 21 17:30:23 kergoth, thanks. My goal is to re-name a file in a package, so I think I really want to append to the package recipe, not the image recipe. What would be the correct way to do something like that Jul 21 17:30:58 do_install is what installs the files into the area that's then broken up into packages Jul 21 17:31:09 just do_install_append and do whatever you want under ${D} Jul 21 17:32:07 Ah, than you - let me give that a shot. Jul 21 17:36:55 Chocobo: if thats the recipe i think it is, you will likely also need to modify do_deploy to rename the output that is populated to the deploy directory Jul 21 17:36:57 So if I add the do_install_append() {} function to the append file, is there a way to see if that is being executed (similar to bitbake -e)? It doesn't seem to be running when "bitbake image-name" Jul 21 17:38:16 Chocobo: your trying to rename files that are built by http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/recipes-bsp/device-tree/device-tree.bb yer? Jul 21 17:38:18 perhaps I need to "bitbake -c clean device-tree"? I am not sure how the state is tracked. Jul 21 17:39:05 nrossi, yes - I want to create a layer (not modify meta-xilinx) that renames one of the devicetree files populated by that recipe. Jul 21 17:39:49 Chocobo: easiest way to do that is to put in a "mv foo.dtb bar.dtb" as a do_compile_append Jul 21 17:41:09 nrossi, why is that better than a do_deploy_append? Jul 21 17:41:39 Chocobo: saves having to put appends to both do_install and do_deploy. Jul 21 17:41:48 Right now I am just trying to do this and it doesn't work: do_install_append() { echo "Hello" > ${D}/test_append_works } Jul 21 17:42:13 Chocobo: though out of curiosity why do you need to rename any of device trees it builds? Jul 21 17:43:19 Chocobo: use "bitbake device-tree -e" and look for the do_install function, make sure it contains your appended part Jul 21 17:43:26 nrossi, our system deployed in the field is expecting a different name in the u-boot environment. This will prevent having to change that env. Jul 21 17:44:18 Chocobo: so you are using a picozed/microzed or similar? Jul 21 17:47:11 nrossi, custom board. I am trying to port our buildroot based system over to oe/yocto. We have several devices based on Zynq and it is getting unmanageable. Jul 21 17:47:24 Hmmm my line _is_ in the do_install. Jul 21 17:47:28 Interesting. Jul 21 17:47:54 Chocobo: try, "bitbake -c cleansstate device-tree" and then build again, will ensure nothing is kept Jul 21 17:49:55 I did the cleansstate and then re-ran "bitbake image-name" and this is what I get: NOTE: Tasks Summary: Attempted 3372 tasks of which 3372 didn't need to be rerun and all succeeded. Jul 21 17:50:24 Chocobo: does your image depend on 'device-tree'? if not then it wont be built. Jul 21 17:51:15 Chocobo: But that leads to a separate question, are your custom device trees added to the SRC_URI of device-tree? or are they coming from the kernel? Jul 21 17:53:05 I haven't gotten that far yet. This is really just a task along the path to the final goal. Out devicetree file will probably be in SRC_URI, although we do keep a fork of the xilinx kernel for in-house bug fixes. Jul 21 17:53:41 Chocobo: using one of the existing meta-xilinx machines or a custom one? Jul 21 17:53:55 Chocobo: if one of the meta-xilinx machines which one? Jul 21 17:54:47 Our image has "kernel-devicetree" as an IMAGE_INSTALL, is that what you mean by the image depending on the recipe? Jul 21 17:55:22 nrossi, right now I am using the existing one (zcu102-zynqmp) Jul 21 17:57:44 Chocobo: oh well that explains your issues. 'kernel-devicetree' is a package from the kernel, and thus only have kernel built device trees. The 'device-tree' recipe is mainly for dt's that are not in kernel source. For zcu102-zynqmp, that only has kernel device trees. But device-tree will still work, just add 'device-tree' to IMAGE_INSTALL or to EXTRA_IMAGEDEPENDS. Jul 21 17:58:48 (it just wont build anything because there are no dts's in device-tree/files/ for zcu102) Jul 21 18:00:31 Ah, so what I really want to do is kernel-devicetree do_compile_append ? I added device-tree and it is doing something now :) Jul 21 18:02:38 Chocobo: its a little bit different. So assuming you are using "linux-xlnx" kernel. Then you will need to make a linux-xlnx_%.bbappend, and you will need to make the "mv" in do_install and do_deploy Jul 21 18:08:54 Yeah, it fails when I include device-tree in the image because there are no dts files to compile. That is fine, I will create a linux-xlnx append. Why do I need to do the move in both do_install and do_deploy? from reading the docs on those it isn't exactly clear on what is happening at each step. Jul 21 18:10:12 Chocobo: do_install -> install files into root filesystem (e.g. for dtb's /boot/...), do_deploy -> deploy files into a directory on build host (tmp/deploy/images//) Jul 21 18:12:46 So do_deploy sounds optional, files put in place by do_install are what gets packed up into a image? Both of those are sourced from package directory? Jul 21 18:13:15 sorry for the questions. This is considerably more flexible/difficult than buildroot. Jul 21 18:15:13 Chocobo: np, it all depend on how you boot, and how you prepare your image. For example you may be populating the dtb into flash, so do_deploy makes sense. If you are booting from the sdcard via the rootfs partition do_install make sense. Jul 21 18:17:01 Chocobo: if you are booting from sd but your device tree is in for example the fat partition, it needs to be put there separately from the rootfs. Either manually or via tooling like 'wic', which uses the content in the deploy directory. Jul 21 18:20:15 wic is on my list of thing to look into. Ok, so I am getting closer! my do_install_append is running. Thank you for the help. Instead of doing a move I am making a symlink, interestingly "ln -s ${D}/boot/*revB*.dtb ${D}/boot/devicetree.dts" creates a symlink that points to the wrong place. Jul 21 18:21:22 Actually it worked correctly. Jul 21 18:21:24 Chocobo: thats an absolute symlink, .... bad idea for populating to the target Jul 21 18:21:39 Yeah, I need to symlink to ./ Jul 21 18:22:10 Chocobo: this would work better "ln -s $(basename ${D}/boot/*revB*.dtb) ${D}/boot/devicetree.dtb" Jul 21 18:23:18 Ah, thanks. I will try that. I am experimenting with doing a "cd ${D}/boot/" before doing the symlink Jul 21 18:23:43 Oh man, this is great. Thank you so much. Jul 21 18:24:08 Chocobo: that works too, but careful since you are changing the directory of the task, i recommend doing it in a subshell, aka (cd ${D}/boot; whatever) Jul 21 18:25:13 the basename approach is a lot better. Jul 21 18:26:08 Ok, so I think I would have been a lot closer initially if I hadn't gotten confused on which recipe was providing a file. Jul 21 20:20:33 From the Bitbake manual, "3.1.6 Immediate variable expansion (:=)", shouldn't the value of `A` from `T = "123"\n A := "${B} ${A} test ${T}"` be `${B} ${A} test 123` because the manual says that if a variable is undefined the literal reference to it remains? http://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html#immediate-variable-expansion Jul 21 20:38:43 Since it matters over here too Jul 21 20:38:56 I found where stacked CONVERSION_CMD stuff got broken Jul 21 20:39:12 And also, I need to make the image_types_uboot stuff stop being a second class citizen Jul 21 20:40:01 (Why? Well, in part because it's so bloody useful for everything not-x86, and in part, because what I strongly suspect to be oddities in that code caused an incorrect fix to the problem up in the more generic code) Jul 21 20:43:03 Yup, mutter and sigh Jul 21 21:16:48 hi all Jul 21 21:19:11 [master 1892ce96c3e4] image_types.bbclass: Make u-boot signed images more versatile Jul 21 21:19:11 3 files changed, 4 insertions(+), 40 deletions(-) Jul 21 21:19:11 delete mode 100644 meta/classes/image_types_uboot.bbclass Jul 21 21:20:00 Testing spitting out all of the types image_types_uboot supported before, plus .ext4.xz.u-boot, which I wanted a bit ago, but OE didn't support Jul 21 21:33:02 hi all, may I ask someone for a review on this patch? https://patchwork.openembedded.org/patch/142009/ Jul 21 21:39:21 gportay: Er, where do you have a kernel that makes a fitImage ? Jul 21 21:39:55 Or are you saying something else is going on? Jul 21 21:48:29 Tartarus: A home made distribution using arago Jul 21 21:55:00 Tartarus: before the patch, kernel_do_deploy was installing linux.bin which is a zImage as fitImage-... Jul 21 22:07:11 woo, worked, patches posted Jul 21 22:07:33 gportay: That sounds odd, I wonder if meta-arago is doing something off? I woudl expect some people to note/complain if FIT was broken Jul 21 22:07:42 But frankly, I know how much TI uses FIT too, so I'm very puzzled Jul 21 22:18:20 Tartarus: it is because they are using a FIT with initramfs (fit-image-${INITRAMFS_IMAGE}.its) not the FIT w/out initramfs (fit-image.its) Jul 21 22:18:31 ah Jul 21 22:18:45 Tartarus: there are two functions, do_assemble_fitimage and do_assemble_fitimage_initramfs Jul 21 22:19:40 ah, ok Jul 21 22:19:42 thanks Jul 21 22:20:07 your welcome Jul 21 22:20:09 :) Jul 21 22:45:32 Tartarus, hey, long I don't bother you ;) Jul 21 22:47:01 talking with Marex about gcc7 vs kernel I'd put you in cc as weel. The e-mail @k....o.com is ok? Jul 21 22:54:59 yeah, thanks ant_home Jul 21 23:10:48 tia, gn Jul 22 00:39:30 Tartarus: still here? Jul 22 00:43:46 denix: pong Jul 22 00:45:48 Tartarus: the issue gportay mentioned is real Jul 22 00:46:09 Tartarus: but, it only affects one of .itb files Jul 22 00:47:59 Ah, ok Jul 22 00:48:51 Tartarus: so, the class generates following files: fitImage, pair of .its+.itb for kernel-only (fitImage-linux.bin.{its|itb}) and also a pair of ramdisk-enabled .its+.itb files (fitImage-ramdiskname.{its|itb}) Jul 22 00:49:38 Tartarus: so, our of those 5 files, fitImage-linux.bin.itb ends up being just a kernel image, not FIT with the kernel :) Jul 22 00:50:13 Tartarus: I've been meaning to send a fix for quite some time, but we've been using fitImage instead of fitImage.itb and that works fine Jul 22 00:50:45 ok Jul 22 00:58:00 Tartarus: oops, OE-core still uses .bin extension not .itb - I have to upstream that change as well... :) Jul 22 00:59:12 should be easier than my current tasks :) Jul 22 00:59:21 Add vmdk.xz to AGL, lets upstream that! Jul 22 00:59:38 Tartarus: heh Jul 22 00:59:42 ... fixed chaining compression/conversion being broken, then need to move on to migration of vmdk/etc stuff from hacky hdddirect to wic Jul 22 01:00:45 Tartarus: speaking of chaining compression - I couldn't make it work before for things like .tar.xz.md5sum so would have to check your fix Jul 22 01:01:05 denix: Yeah, it got broken like a month or less after introduction Jul 22 01:01:11 Since the u-boot conversions weren't updated Jul 22 01:01:19 "fixing" that broke everything else Jul 22 01:01:46 huh, sounds familiar Jul 22 01:01:50 moment Jul 22 01:02:38 $ cat tmp-glibc/deploy/images/qemux86/core-image-minimal-qemux86.ext2.xz.u-boot.sha256sum Jul 22 01:02:38 774fa852acf06ba0e0a726c10b20a8a9d4e6c98c650dc882658be0afba2aee48 core-image-minimal-qemux86-20170722010154.rootfs.ext2.xz.u-boot Jul 22 01:02:42 So it would work now :) Jul 22 01:03:12 \o/ Jul 22 01:03:35 real test.. Jul 22 01:04:19 $ sha256sum -c core-image-minimal-qemux86.ext2.xz.u-boot.sha256sum Jul 22 01:04:19 core-image-minimal-qemux86-20170722010313.rootfs.ext2.xz.u-boot: OK Jul 22 01:04:29 ok, afk now :) Jul 22 01:04:43 Tartarus: hopefully I'll be able to test your patches over the weekend and send Tested-by :) Jul 22 01:08:12 thanks! **** ENDING LOGGING AT Sat Jul 22 03:00:03 2017