6290 2014-05-07 23:42:10 +0000 Update WIC for gummiboot 2014-12-17 13:18:18 +0000 1 1 7 Build System, Metadata & Runtime OE-Core deployment unspecified Other Multiple VERIFIED FIXED High enhancement 1.7 M3 6131 1 sgw tom.zanussi alexandru.c.georgescu dvhart maciej.borzecki costin.c.constantin --- --- Yes (doc changes required) oldest_to_newest 43167 0 sgw 2014-05-07 23:42:10 +0000 Gummiboot is now part of the core, but the infrastructure supporting efi is all grub-efi specific. WIC needs to be more generic to handle an efi-plugin and other abstractions. 43284 1 tom.zanussi 2014-05-13 15:58:22 +0000 Whenever I see a 'high' bug assigned to me, I have to ask the knee-jerk questions: - Why is it high? - Why is it M2? As far as the specific requirements, I also need to ask for more details about what is meant by 'efi-plugin' and especially the 'other abstractions' mentioned. Also, what specifically do we need to test in order to consider this fully implemented i.e. specific features to test and specific targets to test them on. 44074 2 sjolley.yp.pm 2014-06-18 17:46:30 +0000 Assigned to person we are requesting info from per RP. 44518 3 dvhart 2014-07-16 22:12:54 +0000 Tom, Marking it high was basically a technique to ensure we finally got the grub to gummiboot transition to happen. It's been > medium(+?) for something like 3 releases and we wanted to get it done. Of course, lots of other things came through the flood gates since then. There's always risk in using the high moniker. M2 was selected to ensure we had time to test the tooling throughout the release rather than toward the end. I just sent patches for Bug 6295 to update mkefidisk.sh to support gummiboot. The gummiboot specific update was very straight forward. I believe you used mkefidisk.sh as a guide for the grub-efi support. You should now be able to use it for gummiboot support as well - hopefully that will reduce the time burden for this particular bug. 44543 4 sgw 2014-07-17 15:14:34 +0000 Reset with more info 44548 5 tom.zanussi 2014-07-17 15:40:24 +0000 OK, understood, and I appreciate the mkefidisk.sh code - it at least avoids the guesswork about what needs to be done. On the other hand, I have to go on record again saying that I don't agree with general philosophy of marking things high so they 'get done'. That wasn't meant to be the purpose of the category and didn't work out too well last time. 44550 6 dvhart 2014-07-17 20:51:33 +0000 Fair enough, and I think in retrospect, I agree with you. Note that the mkefidisk.sh for gummiboot is missing the removal of the initrd line, the same as we do for the grub block. I'll be updating that. 44870 7 dvhart 2014-07-31 14:14:31 +0000 Discussed with Tom, ETA is most likely next week. It won't make M2. Leaving as M2 so Bug Triage can decide how to handle moving to M3. 45176 8 tom.zanussi 2014-08-19 15:15:43 +0000 commit 6e328c94ae402bdf6f664f2bbfd79fdfe7661d03 Author: Tom Zanussi <tom.zanussi@linux.intel.com> Date: Mon Aug 11 20:35:39 2014 -0500 wic: Add gummiboot support to bootimg-efi 45883 9 costin.c.constantin 2014-09-26 06:00:36 +0000 Hello, I tried to test this wic feature, but I can't seem to pass over a step (tried both nuc BSP for nuc and intel-i7_64 BSP for minnowboard max). The config I did in local.conf (aside from setting the MACHINE): ... EFI_PROVIDER = "gummiboot" ... then i do a core-image-minimal. The thing is that when I try to do "wic create mkgummidisk -e core-image-minimal" i get this error message: Checking basic build environment... Done. Creating image(s)... Error: exec_cmd: cp /home/autobuilder/poky/build/tmp/deploy/images/nuc/EFI/BOOT/* /var/tmp/wic/build/hdd/boot/EFI/BOOT returned '1' instead of 0 ... and indeed there is nothing in that directory. tested with: meta-intel : a369fa8f2d76528cb296ef9314e613e26585d54d poky : 8ac8eca2e3bd8c78e2b31ea974930ed0243258a3 Please let me know if I'm missing something. Costin 45920 10 costin.c.constantin 2014-09-29 05:33:17 +0000 *** Bug 6131 has been marked as a duplicate of this bug. *** 46455 11 tom.zanussi 2014-10-20 18:48:11 +0000 I also see the problem, but I retried the original git tree and it works fine, so something changed after it was pulled in: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/wic-gummiboot-v1 [trz@medianoche build]$ wic create mkgummidisk -e core-image-minimal Checking basic build environment... Done. Creating image(s)... Info: The new image(s) can be found here: /var/tmp/wic/build/mkgummidisk-201410201343-sda.direct The following build artifacts were used to create the image(s): ROOTFS_DIR: /usr/local/dev/yocto/wic-test-daisy/build/tmp/work/nuc-poky-linux/core-image-minimal/1.0-r0/rootfs BOOTIMG_DIR: /usr/local/dev/yocto/wic-test-daisy/build/tmp/work/nuc-poky-linux/core-image-minimal/1.0-r0/core-image-minimal-1.0/hddimg KERNEL_DIR: /usr/local/dev/yocto/wic-test-daisy/build/tmp/sysroots/nuc/usr/src/kernel NATIVE_SYSROOT: /usr/local/dev/yocto/wic-test-daisy/build/tmp/sysroots/x86_64-linux The image(s) were created using OE kickstart file: /usr/local/dev/yocto/wic-test-daisy/scripts/lib/image/canned-wks/mkgummidisk.wks 46458 12 tom.zanussi 2014-10-20 21:46:11 +0000 And this is the commit that causes the problem. The wrong value for boot_img_dir is used instead of the expected HDDDIR. commit 7ce1dc13f91df70e8a2f420e7c3eba51cbc4bd48 Author: Maciej Borzecki <maciej.borzecki@open-rnd.pl> Date: Mon Sep 22 13:35:16 2014 +0200 wic: set bootimg_dir when using image-name artifacts 46499 13 costin.c.constantin 2014-10-22 13:57:20 +0000 Hello, I retested the bug and this time the situation changed a litle because the error message is much scarse than before: " cosscat@ubnt:/media/poky/poky/build$ wic create mkgummidisk -e core-image-minimal Checking basic build environment... Done. Creating image(s)... Error: exec_cmd: cp /media/poky/poky/build/tmp/deploy/images/nuc/EFI/BOOT/* /var/tmp/wic/build/hdd/boot/EFI/BOOT returned '1' instead of 0 cosscat@ubnt:/media/poky/poky/build$ " This is my build environment over a fresly cloned poky: cosscat@ubnt:/media/poky/poky/build$ bitbake core-image-minimal Parsing recipes: 100% |##################################################################################################################################################################################################| Time: 00:00:18 Parsing of 910 .bb files complete (0 cached, 910 parsed). 1307 targets, 44 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION = "1.24.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-14.04" TARGET_SYS = "x86_64-poky-linux" MACHINE = "nuc" DISTRO = "poky" DISTRO_VERSION = "1.7" TUNE_FEATURES = "m64 corei7" TARGET_FPU = "" meta meta-yocto meta-yocto-bsp meta-selftest = "(detachedfrom924da20):924da20c6f2f183fa7e930e4c3c6b14c090acbe5" meta-intel meta-nuc = "(detachedfrom9f815ab):9f815ab761e6b524625e4180397233eeb728f84e" NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: Failed to fetch URL ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-2.11.src.tar.gz, attempting MIRRORS if available WARNING: Failed to fetch URL ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-3.01a20.tar.bz2, attempting MIRRORS if available NOTE: validating kernel config, see log.do_kernel_configcheck for details NOTE: Tasks Summary: Attempted 2301 tasks of which 780 didn't need to be rerun and all succeeded. Summary: There were 2 WARNING messages shown. cosscat@ubnt:/media/poky/poky/build$ " The content of the indicated directory contains no EFI dir: cosscat@ubnt:/media/poky/poky/build/tmp/deploy/images/nuc$ ls bzImage core-image-minimal-initramfs-nuc.manifest core-image-minimal-nuc.hddimg modules--3.17-rc4+git0+7df849fc7e_1a3939eb74-r0-nuc-20141022125726.tgz bzImage--3.17-rc4+git0+7df849fc7e_1a3939eb74-r0-nuc-20141022125726.bin core-image-minimal-nuc-20141022125726.hddimg core-image-minimal-nuc.iso modules-nuc.tgz bzImage-nuc.bin core-image-minimal-nuc-20141022125726.iso core-image-minimal-nuc.manifest README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt core-image-minimal-initramfs-nuc-20141022125726.rootfs.cpio.gz core-image-minimal-nuc-20141022125726.rootfs.ext3 gummibootx64.efi core-image-minimal-initramfs-nuc-20141022125726.rootfs.manifest core-image-minimal-nuc-20141022125726.rootfs.manifest microcode_20140624.cpio core-image-minimal-initramfs-nuc.cpio.gz core-image-minimal-nuc.ext3 microcode.cpio cosscat@ubnt:/media/poky/poky/build/tmp/deploy/images/nuc$ cosscat@ubnt:/media/poky/poky/build/tmp/deploy/images/nuc$ Reopening bug. Regards, Costin 46504 14 maciej.borzecki 2014-10-22 15:42:35 +0000 (In reply to comment #13) > Hello, > > I retested the bug and this time the situation changed a litle because the > error message is much scarse than before: > > " > cosscat@ubnt:/media/poky/poky/build$ wic create mkgummidisk -e > core-image-minimal > Checking basic build environment... > Done. > > Creating image(s)... > > Error: exec_cmd: cp /media/poky/poky/build/tmp/deploy/images/nuc/EFI/BOOT/* > /var/tmp/wic/build/hdd/boot/EFI/BOOT returned '1' instead of 0 > cosscat@ubnt:/media/poky/poky/build$ > " Indeed, this looks like my doing. I'll try to look into this. Can you post output of: wic create -D .. 46507 15 costin.c.constantin 2014-10-22 17:13:27 +0000 Hello, As of last comment, I've attached a file with wic debug's output. Costin 46508 16 2207 costin.c.constantin 2014-10-22 17:14:08 +0000 Created attachment 2207 debug output 46565 17 tom.zanussi 2014-10-24 15:01:22 +0000 Shouldn't the patch: commit 7ce1dc13f91df70e8a2f420e7c3eba51cbc4bd48 Author: Maciej Borzecki <maciej.borzecki@open-rnd.pl> Date: Mon Sep 22 13:35:16 2014 +0200 wic: set bootimg_dir when using image-name artifacts just be reverted? AFAICT, it was added so that bootimg-partition would have DEPLOY_DIR_IMAGE, but bootimg-partition doesn't even use the bootimg_dir value except to print somthing out, and then does a get_bitbake_var("DEPLOY_DIR_IMAGE") anyway. 46569 18 maciej.borzecki 2014-10-24 15:51:38 +0000 (In reply to comment #17) > Shouldn't the patch: > > commit 7ce1dc13f91df70e8a2f420e7c3eba51cbc4bd48 > Author: Maciej Borzecki <maciej.borzecki@open-rnd.pl> > Date: Mon Sep 22 13:35:16 2014 +0200 > > wic: set bootimg_dir when using image-name artifacts > > just be reverted? AFAICT, it was added so that bootimg-partition would have > DEPLOY_DIR_IMAGE, but bootimg-partition doesn't even use the bootimg_dir > value except to print somthing out, and then does a > get_bitbake_var("DEPLOY_DIR_IMAGE") anyway. Before the patch, bootimg_dir was always be empty in this call in wic_create_subcommand(): wic_create(args, wks_file, rootfs_dir, bootimg_dir, kernel_dir, native_sysroot, hdddir, staging_data_dir, scripts_path, image_output_dir, options.debug, options.properties_file) That's because it was initialized to "" but never assigned when calling find_artifacts(). Then, down in the source plugin, in do_prepare_partition() call, bootimg_dir would also be empty. My intention was to have this variable hold a path to the location where boot related files might be located. Now, as a sane default, bootimg_dir ends up being set to $DEPLOY_DIR_IMAGE (as for instance u-boot files end up in this location, so I felt that it'd be natural to use that location). Then in source plugin, in do_prepare_partition() instead of calling get_bitbake_var("DEPLOY_DIR_IMAGE") like bootimg-partition does now, you could directly use bootimg_dir. Hopefully, the explanation is convincing :) 46571 19 maciej.borzecki 2014-10-24 16:13:30 +0000 (In reply to comment #18) > (In reply to comment #17) > > Shouldn't the patch: > > > > commit 7ce1dc13f91df70e8a2f420e7c3eba51cbc4bd48 > > Author: Maciej Borzecki <maciej.borzecki@open-rnd.pl> > > Date: Mon Sep 22 13:35:16 2014 +0200 > > > > wic: set bootimg_dir when using image-name artifacts > > > > just be reverted? AFAICT, it was added so that bootimg-partition would have > > DEPLOY_DIR_IMAGE, but bootimg-partition doesn't even use the bootimg_dir > > value except to print somthing out, and then does a > > get_bitbake_var("DEPLOY_DIR_IMAGE") anyway. > > Before the patch, bootimg_dir was always be empty in this call in > wic_create_subcommand(): > > wic_create(args, wks_file, rootfs_dir, bootimg_dir, kernel_dir, > native_sysroot, hdddir, staging_data_dir, scripts_path, > image_output_dir, options.debug, options.properties_file) > > That's because it was initialized to "" but never assigned when calling > find_artifacts(). Then, down in the source plugin, in do_prepare_partition() > call, bootimg_dir would also be empty. > > My intention was to have this variable hold a path to the location where > boot related files might be located. Now, as a sane default, bootimg_dir > ends up being set to $DEPLOY_DIR_IMAGE (as for instance u-boot files end up > in this location, so I felt that it'd be natural to use that location). Then > in source plugin, in do_prepare_partition() instead of calling > get_bitbake_var("DEPLOY_DIR_IMAGE") like bootimg-partition does now, you > could directly use bootimg_dir. > > Hopefully, the explanation is convincing :) I assume that bootimg_dir and hdddir we expected to be different at some point, so perhaps passing hdddir explicitly do do_prepare_partition() would be a good solution. Tom, what do you think? 46572 20 tom.zanussi 2014-10-24 16:35:00 +0000 Well, it should probably be explicitly stated somewhere, but the intention of bootimg_dir is that it allows the plugin to distinguish between a value explicitly specified by the user (using -b) or if not set, it's up to the plugin to find. Which was why the get_bitbake_var() function was added, so that plugins could find those variables as needed, and the existing plugins do that - e.g. the basic pattern is 'if !bootimg_dir bootimg_dir = get_bitbake_var()'. So with the value now being hardcoded to the value of get_bitbake_var("DEPLOY_DIR_IMAGE") every plugin sees that value and assumes it was the value passed in by the user and just takes it. Which is fine for u-boot but breaks everything else. So I think I'll have to fix this up so that things work for everyone, but so far I haven't been successful creating a u-boot build to to test this with - could you post details on how I can test what I fix so that it works for u-boot? In 1.8, we really need to have a testsuite that we run wic through to verify that a change doesn't break any use case we care about - I already have that in the plan for 1.8. 46574 21 maciej.borzecki 2014-10-24 18:06:27 +0000 (In reply to comment #20) > Well, it should probably be explicitly stated somewhere, but the intention > of bootimg_dir is that it allows the plugin to distinguish between a value > explicitly specified by the user (using -b) or if not set, it's up to the > plugin to find. Which was why the get_bitbake_var() function was added, so > that plugins could find those variables as needed, and the existing plugins > do that - e.g. the basic pattern is 'if !bootimg_dir bootimg_dir = > get_bitbake_var()'. > > So with the value now being hardcoded to the value of > get_bitbake_var("DEPLOY_DIR_IMAGE") every plugin sees that value and assumes > it was the value passed in by the user and just takes it. Which is fine for > u-boot but breaks everything else. > > So I think I'll have to fix this up so that things work for everyone, but so > far I haven't been successful creating a u-boot build to to test this with - > could you post details on how I can test what I fix so that it works for > u-boot? > > In 1.8, we really need to have a testsuite that we run wic through to verify > that a change doesn't break any use case we care about - I already have that > in the plan for 1.8. It should be fine to revert 7ce1dc13f91df70e8a2f420e7c3eba51cbc4bd48 then. I somehow missed that fact that empty var means that it had not been set explicitly. As for testing, that's definitely a good idea. I've started using pylint with current code, but so far it's a bit problematic. Pylint does not handle live patching of objects or calling methods from named keys in dict too well. 46688 22 tom.zanussi 2014-10-30 16:27:25 +0000 This should now be fixed in master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=38400617febd61a1594969c86a6f1712a9d80516 47601 23 costin.c.constantin 2014-12-17 13:18:18 +0000 Hello, Tested on Minnow Max with an core-i7_64 image, and it works. No more errors with wic. Marking as verified. Costin 2207 2014-10-22 17:14:08 +0000 2014-10-22 17:14:08 +0000 debug output wic_debug_output.txt text/plain 5736 costin.c.constantin Y29zc2NhdEB1Ym50Oi9tZWRpYS9wb2t5L3Bva3kvYnVpbGQkIHdpYyBjcmVhdGUgLUQgbWtndW1t aWRpc2sgLWUgY29yZS1pbWFnZS1taW5pbWFsDQpDaGVja2luZyBiYXNpYyBidWlsZCBlbnZpcm9u bWVudC4uLg0KRG9uZS4NCg0KQ3JlYXRpbmcgaW1hZ2UocykuLi4NCg0KRGVidWc6IFBsdWdpbiBk aXIgaXMgbm90IGEgZGlyZWN0b3J5IG9yIGRvZXMgbm90IGV4aXN0OiAvbWVkaWEvcG9reS9wb2t5 L21ldGEvc2NyaXB0cy9saWIvd2ljL3BsdWdpbnMvaW1hZ2VyDQpEZWJ1ZzogUGx1Z2luIGRpciBp cyBub3QgYSBkaXJlY3Rvcnkgb3IgZG9lcyBub3QgZXhpc3Q6IC9tZWRpYS9wb2t5L3Bva3kvbWV0 YS15b2N0by9zY3JpcHRzL2xpYi93aWMvcGx1Z2lucy9pbWFnZXINCkRlYnVnOiBQbHVnaW4gZGly IGlzIG5vdCBhIGRpcmVjdG9yeSBvciBkb2VzIG5vdCBleGlzdDogL21lZGlhL3Bva3kvcG9reS9t ZXRhLXlvY3RvLWJzcC9zY3JpcHRzL2xpYi93aWMvcGx1Z2lucy9pbWFnZXINCkRlYnVnOiBQbHVn aW4gZGlyIGlzIG5vdCBhIGRpcmVjdG9yeSBvciBkb2VzIG5vdCBleGlzdDogL21lZGlhL3Bva3kv cG9reS9tZXRhLXNlbGZ0ZXN0L3NjcmlwdHMvbGliL3dpYy9wbHVnaW5zL2ltYWdlcg0KRGVidWc6 IFBsdWdpbiBkaXIgaXMgbm90IGEgZGlyZWN0b3J5IG9yIGRvZXMgbm90IGV4aXN0OiAvbWVkaWEv cG9reS9wb2t5L21ldGEtaW50ZWwvc2NyaXB0cy9saWIvd2ljL3BsdWdpbnMvaW1hZ2VyDQpEZWJ1 ZzogUGx1Z2luIGRpciBpcyBub3QgYSBkaXJlY3Rvcnkgb3IgZG9lcyBub3QgZXhpc3Q6IC9tZWRp YS9wb2t5L3Bva3kvbWV0YS1pbnRlbC9tZXRhLW51Yy9zY3JpcHRzL2xpYi93aWMvcGx1Z2lucy9p bWFnZXINCkRlYnVnOiBQbHVnaW4gbW9kdWxlIGRpcmVjdF9wbHVnaW46L21lZGlhL3Bva3kvcG9r eS9zY3JpcHRzL2xpYi93aWMvcGx1Z2lucy9pbWFnZXIvZGlyZWN0X3BsdWdpbi5weWMgaW1wb3J0 ZWQNCkRlYnVnOiBQbHVnaW4gZGlyIGlzIG5vdCBhIGRpcmVjdG9yeSBvciBkb2VzIG5vdCBleGlz dDogL21lZGlhL3Bva3kvcG9reS9tZXRhL3NjcmlwdHMvbGliL3dpYy9wbHVnaW5zL3NvdXJjZQ0K RGVidWc6IFBsdWdpbiBkaXIgaXMgbm90IGEgZGlyZWN0b3J5IG9yIGRvZXMgbm90IGV4aXN0OiAv bWVkaWEvcG9reS9wb2t5L21ldGEteW9jdG8vc2NyaXB0cy9saWIvd2ljL3BsdWdpbnMvc291cmNl DQpEZWJ1ZzogUGx1Z2luIGRpciBpcyBub3QgYSBkaXJlY3Rvcnkgb3IgZG9lcyBub3QgZXhpc3Q6 IC9tZWRpYS9wb2t5L3Bva3kvbWV0YS15b2N0by1ic3Avc2NyaXB0cy9saWIvd2ljL3BsdWdpbnMv c291cmNlDQpEZWJ1ZzogUGx1Z2luIGRpciBpcyBub3QgYSBkaXJlY3Rvcnkgb3IgZG9lcyBub3Qg ZXhpc3Q6IC9tZWRpYS9wb2t5L3Bva3kvbWV0YS1zZWxmdGVzdC9zY3JpcHRzL2xpYi93aWMvcGx1 Z2lucy9zb3VyY2UNCkRlYnVnOiBQbHVnaW4gZGlyIGlzIG5vdCBhIGRpcmVjdG9yeSBvciBkb2Vz IG5vdCBleGlzdDogL21lZGlhL3Bva3kvcG9reS9tZXRhLWludGVsL3NjcmlwdHMvbGliL3dpYy9w bHVnaW5zL3NvdXJjZQ0KRGVidWc6IFBsdWdpbiBkaXIgaXMgbm90IGEgZGlyZWN0b3J5IG9yIGRv ZXMgbm90IGV4aXN0OiAvbWVkaWEvcG9reS9wb2t5L21ldGEtaW50ZWwvbWV0YS1udWMvc2NyaXB0 cy9saWIvd2ljL3BsdWdpbnMvc291cmNlDQpEZWJ1ZzogUGx1Z2luIG1vZHVsZSBib290aW1nLXBh cnRpdGlvbjovbWVkaWEvcG9reS9wb2t5L3NjcmlwdHMvbGliL3dpYy9wbHVnaW5zL3NvdXJjZS9i b290aW1nLXBhcnRpdGlvbi5weWMgaW1wb3J0ZWQNCkRlYnVnOiBQbHVnaW4gbW9kdWxlIGJvb3Rp bWctZWZpOi9tZWRpYS9wb2t5L3Bva3kvc2NyaXB0cy9saWIvd2ljL3BsdWdpbnMvc291cmNlL2Jv b3RpbWctZWZpLnB5YyBpbXBvcnRlZA0KRGVidWc6IFBsdWdpbiBtb2R1bGUgcm9vdGZzOi9tZWRp YS9wb2t5L3Bva3kvc2NyaXB0cy9saWIvd2ljL3BsdWdpbnMvc291cmNlL3Jvb3Rmcy5weWMgaW1w b3J0ZWQNCkRlYnVnOiBQbHVnaW4gbW9kdWxlIGJvb3RpbWctcGNiaW9zOi9tZWRpYS9wb2t5L3Bv a3kvc2NyaXB0cy9saWIvd2ljL3BsdWdpbnMvc291cmNlL2Jvb3RpbWctcGNiaW9zLnB5YyBpbXBv cnRlZA0KRGVidWc6IFBsdWdpbiBkaXIgaXMgbm90IGEgZGlyZWN0b3J5IG9yIGRvZXMgbm90IGV4 aXN0OiAvbWVkaWEvcG9reS9wb2t5L21ldGEvc2NyaXB0cy9saWIvd2ljL3BsdWdpbnMvc291cmNl DQpEZWJ1ZzogUGx1Z2luIGRpciBpcyBub3QgYSBkaXJlY3Rvcnkgb3IgZG9lcyBub3QgZXhpc3Q6 IC9tZWRpYS9wb2t5L3Bva3kvbWV0YS15b2N0by9zY3JpcHRzL2xpYi93aWMvcGx1Z2lucy9zb3Vy Y2UNCkRlYnVnOiBQbHVnaW4gZGlyIGlzIG5vdCBhIGRpcmVjdG9yeSBvciBkb2VzIG5vdCBleGlz dDogL21lZGlhL3Bva3kvcG9reS9tZXRhLXlvY3RvLWJzcC9zY3JpcHRzL2xpYi93aWMvcGx1Z2lu cy9zb3VyY2UNCkRlYnVnOiBQbHVnaW4gZGlyIGlzIG5vdCBhIGRpcmVjdG9yeSBvciBkb2VzIG5v dCBleGlzdDogL21lZGlhL3Bva3kvcG9reS9tZXRhLXNlbGZ0ZXN0L3NjcmlwdHMvbGliL3dpYy9w bHVnaW5zL3NvdXJjZQ0KRGVidWc6IFBsdWdpbiBkaXIgaXMgbm90IGEgZGlyZWN0b3J5IG9yIGRv ZXMgbm90IGV4aXN0OiAvbWVkaWEvcG9reS9wb2t5L21ldGEtaW50ZWwvc2NyaXB0cy9saWIvd2lj L3BsdWdpbnMvc291cmNlDQpEZWJ1ZzogUGx1Z2luIGRpciBpcyBub3QgYSBkaXJlY3Rvcnkgb3Ig ZG9lcyBub3QgZXhpc3Q6IC9tZWRpYS9wb2t5L3Bva3kvbWV0YS1pbnRlbC9tZXRhLW51Yy9zY3Jp cHRzL2xpYi93aWMvcGx1Z2lucy9zb3VyY2UNCkRlYnVnOiBQbHVnaW4gZGlyIGlzIG5vdCBhIGRp cmVjdG9yeSBvciBkb2VzIG5vdCBleGlzdDogL21lZGlhL3Bva3kvcG9reS9tZXRhL3NjcmlwdHMv bGliL3dpYy9wbHVnaW5zL3NvdXJjZQ0KRGVidWc6IFBsdWdpbiBkaXIgaXMgbm90IGEgZGlyZWN0 b3J5IG9yIGRvZXMgbm90IGV4aXN0OiAvbWVkaWEvcG9reS9wb2t5L21ldGEteW9jdG8vc2NyaXB0 cy9saWIvd2ljL3BsdWdpbnMvc291cmNlDQpEZWJ1ZzogUGx1Z2luIGRpciBpcyBub3QgYSBkaXJl Y3Rvcnkgb3IgZG9lcyBub3QgZXhpc3Q6IC9tZWRpYS9wb2t5L3Bva3kvbWV0YS15b2N0by1ic3Av c2NyaXB0cy9saWIvd2ljL3BsdWdpbnMvc291cmNlDQpEZWJ1ZzogUGx1Z2luIGRpciBpcyBub3Qg YSBkaXJlY3Rvcnkgb3IgZG9lcyBub3QgZXhpc3Q6IC9tZWRpYS9wb2t5L3Bva3kvbWV0YS1zZWxm dGVzdC9zY3JpcHRzL2xpYi93aWMvcGx1Z2lucy9zb3VyY2UNCkRlYnVnOiBQbHVnaW4gZGlyIGlz IG5vdCBhIGRpcmVjdG9yeSBvciBkb2VzIG5vdCBleGlzdDogL21lZGlhL3Bva3kvcG9reS9tZXRh LWludGVsL3NjcmlwdHMvbGliL3dpYy9wbHVnaW5zL3NvdXJjZQ0KRGVidWc6IFBsdWdpbiBkaXIg aXMgbm90IGEgZGlyZWN0b3J5IG9yIGRvZXMgbm90IGV4aXN0OiAvbWVkaWEvcG9reS9wb2t5L21l dGEtaW50ZWwvbWV0YS1udWMvc2NyaXB0cy9saWIvd2ljL3BsdWdpbnMvc291cmNlDQpEZWJ1Zzog X19leGVjX2NtZDogcm0gLXJmIC92YXIvdG1wL3dpYy9idWlsZA0KRGVidWc6IHJtDQotcmYNCi92 YXIvdG1wL3dpYy9idWlsZA0KRGVidWc6IF9fZXhlY19jbWQ6IG91dHB1dCBmb3Igcm0gLXJmIC92 YXIvdG1wL3dpYy9idWlsZCAocmMgPSAwKToNCkRlYnVnOiBfX2V4ZWNfY21kOiBpbnN0YWxsIC1k IC92YXIvdG1wL3dpYy9idWlsZC9oZGQvYm9vdC9FRkkvQk9PVA0KRGVidWc6IGluc3RhbGwNCi1k DQovdmFyL3RtcC93aWMvYnVpbGQvaGRkL2Jvb3QvRUZJL0JPT1QNCkRlYnVnOiBfX2V4ZWNfY21k OiBvdXRwdXQgZm9yIGluc3RhbGwgLWQgL3Zhci90bXAvd2ljL2J1aWxkL2hkZC9ib290L0VGSS9C T09UIChyYyA9IDApOg0KRGVidWc6IF9fZXhlY19jbWQ6IGluc3RhbGwgLWQgL3Zhci90bXAvd2lj L2J1aWxkL2hkZC9ib290L2xvYWRlcg0KRGVidWc6IGluc3RhbGwNCi1kDQovdmFyL3RtcC93aWMv YnVpbGQvaGRkL2Jvb3QvbG9hZGVyDQpEZWJ1ZzogX19leGVjX2NtZDogb3V0cHV0IGZvciBpbnN0 YWxsIC1kIC92YXIvdG1wL3dpYy9idWlsZC9oZGQvYm9vdC9sb2FkZXIgKHJjID0gMCk6DQpEZWJ1 ZzogX19leGVjX2NtZDogaW5zdGFsbCAtZCAvdmFyL3RtcC93aWMvYnVpbGQvaGRkL2Jvb3QvbG9h ZGVyL2VudHJpZXMNCkRlYnVnOiBpbnN0YWxsDQotZA0KL3Zhci90bXAvd2ljL2J1aWxkL2hkZC9i b290L2xvYWRlci9lbnRyaWVzDQpEZWJ1ZzogX19leGVjX2NtZDogb3V0cHV0IGZvciBpbnN0YWxs IC1kIC92YXIvdG1wL3dpYy9idWlsZC9oZGQvYm9vdC9sb2FkZXIvZW50cmllcyAocmMgPSAwKToN CkRlYnVnOiBXcml0aW5nIGd1bW1pYm9vdCBjb25maWcgL3Zhci90bXAvd2ljL2J1aWxkL2hkZC9i b290L2xvYWRlci9sb2FkZXIuY29uZg0KRGVidWc6IFdyaXRpbmcgZ3VtbWlib290IGNvbmZpZyAv dmFyL3RtcC93aWMvYnVpbGQvaGRkL2Jvb3QvbG9hZGVyL2VudHJpZXMvYm9vdC5jb25mDQpEZWJ1 ZzogU291cmNlUGx1Z2luOiBkb19zdGFnZV9wYXJ0aXRpb246IHBhcnQ6IHBhcnQgL2Jvb3QgLS1h Y3RpdmUgLS1vbmRpc2s9c2RhIC0tYnl0ZXMtcGVyLWlub2RlPTQwOTYgLS1sYWJlbD1tc2RvcyAt LWFsaWduIC0tc291cmNlPWJvb3RpbWctZWZpIC0tc291cmNlcGFyYW1zPWxvYWRlcj1ndW1taWJv b3QNCg0KRGVidWc6IF9fZXhlY19jbWQ6IGluc3RhbGwgLW0gMDY0NCAvbWVkaWEvcG9reS9wb2t5 L2J1aWxkL3RtcC9zeXNyb290cy9udWMvdXNyL3NyYy9rZXJuZWwvYnpJbWFnZSAvdmFyL3RtcC93 aWMvYnVpbGQvaGRkL2Jvb3QvYnpJbWFnZQ0KRGVidWc6IGluc3RhbGwNCi1tDQowNjQ0DQovbWVk aWEvcG9reS9wb2t5L2J1aWxkL3RtcC9zeXNyb290cy9udWMvdXNyL3NyYy9rZXJuZWwvYnpJbWFn ZQ0KL3Zhci90bXAvd2ljL2J1aWxkL2hkZC9ib290L2J6SW1hZ2UNCkRlYnVnOiBfX2V4ZWNfY21k OiBvdXRwdXQgZm9yIGluc3RhbGwgLW0gMDY0NCAvbWVkaWEvcG9reS9wb2t5L2J1aWxkL3RtcC9z eXNyb290cy9udWMvdXNyL3NyYy9rZXJuZWwvYnpJbWFnZSAvdmFyL3RtcC93aWMvYnVpbGQvaGRk L2Jvb3QvYnpJbWFnZSAocmMgPSAwKToNCkRlYnVnOiBfX2V4ZWNfY21kOiBjcCAvbWVkaWEvcG9r eS9wb2t5L2J1aWxkL3RtcC9kZXBsb3kvaW1hZ2VzL251Yy9FRkkvQk9PVC8qIC92YXIvdG1wL3dp Yy9idWlsZC9oZGQvYm9vdC9FRkkvQk9PVA0KRGVidWc6IGNwDQovbWVkaWEvcG9reS9wb2t5L2J1 aWxkL3RtcC9kZXBsb3kvaW1hZ2VzL251Yy9FRkkvQk9PVC8qDQovdmFyL3RtcC93aWMvYnVpbGQv aGRkL2Jvb3QvRUZJL0JPT1QNCkRlYnVnOiBfX2V4ZWNfY21kOiBvdXRwdXQgZm9yIGNwIC9tZWRp YS9wb2t5L3Bva3kvYnVpbGQvdG1wL2RlcGxveS9pbWFnZXMvbnVjL0VGSS9CT09ULyogL3Zhci90 bXAvd2ljL2J1aWxkL2hkZC9ib290L0VGSS9CT09UIChyYyA9IDEpOiBjcDogY2Fubm90IHN0YXQg kS9tZWRpYS9wb2t5L3Bva3kvYnVpbGQvdG1wL2RlcGxveS9pbWFnZXMvbnVjL0VGSS9CT09ULyqS OiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5DQpFcnJvcjogZXhlY19jbWQ6IGNwIC9tZWRpYS9w b2t5L3Bva3kvYnVpbGQvdG1wL2RlcGxveS9pbWFnZXMvbnVjL0VGSS9CT09ULyogL3Zhci90bXAv d2ljL2J1aWxkL2hkZC9ib290L0VGSS9CT09UIHJldHVybmVkICcxJyBpbnN0ZWFkIG9mIDANCmNv c3NjYXRAdWJudDovbWVkaWEvcG9reS9wb2t5L2J1aWxkJA0K