1100 2011-05-25 08:07:08 +0000 [emenlow/crownbay-noemgd] X window could not start up with sato-sdk image 2011-05-31 01:55:50 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-configuration unspecified All Multiple VERIFIED FIXED High critical 1.1 M1 1 jiajun.xu dexuan.cui bluelightning dexuan.cui dvhart richard.purdie sgw tom.zanussi yp.bsp.watcher yp.watcher --- --- --- oldest_to_newest 13975 0 jiajun.xu 2011-05-25 08:07:08 +0000 Tree/Branch: Poky/1.1_M1 Poky Commit: fc55b224caa3eeac4abda099ec9ed505db59fb28 Meta Branch: 1.1_M1 Meta Commit: 1b227f8ed2df529cc13f7169b0c08ff3d0f8c812 Image Location: emenlow: http://autobuilder02.pokylinux.org/emenlow/nightly/20110521-1/machines/emenlow/x86_32/core-image-sato-sdk-live-emenlow-20110521070906.hddimg.bz2 crownbay: http://autobuilder02.pokylinux.org/crownbay-noemgd/nightly/20110520-1/machines/crownbay/x86_32/core-image-sato-sdk-live-crownbay-noemgd-20110521035553.hddimg.bz2 blacksand: http://autobuilder02.pokylinux.org/n450/nightly/20110521-1/machines/n450/x86_32/core-image-sato-sdk-live-n450-20110521102330.hddimg.bz2 With Yocto 1.1 M1 RC1 build, some -live BSP images could not have X window start up when booting from USB stick. Parts of error messages are as below(I will attach detailed log tomorrow) ######## failed to load module "intel" (module does not exist , 0) No drivers available ....... Fatal server error: no screens found xinit give up xinit unable to commect to x server connection refused ######## 13977 1 tom.zanussi 2011-05-25 10:06:13 +0000 Sounds like it could be a duplicate of 1072 (machine-specific xorg.confs not being picked up) e.g. crownbay shouldn't even be looking for module "intel". 13992 2 dexuan.cui 2011-05-26 01:12:09 +0000 (In reply to comment #0) > Tree/Branch: Poky/1.1_M1 > Poky Commit: fc55b224caa3eeac4abda099ec9ed505db59fb28 > Meta Branch: 1.1_M1 > Meta Commit: 1b227f8ed2df529cc13f7169b0c08ff3d0f8c812 Hi Jiajun, how did you know the meta commit 1b227f? The autobuilder's file gitinfo only shows the commit number of poky master. (In reply to comment #1) > Sounds like it could be a duplicate of 1072 (machine-specific xorg.confs not > being picked up) e.g. crownbay shouldn't even be looking for module "intel". Agree. I checked the file core-image-sato-sdk-live-emenlow-20110521070906.hddimg.bz2 and the file xorg.conf in it is from meta/recipes-graphics/xorg-xserver/xserver-xf86-config/xorg.conf rather than meta-intel/meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow/xorg.conf. I'm not sure what caused this, however, with MACHINE="emenlow", when I did "bitbake xserver-xf86-config -c unpack -f", I found tmp/work/emenlow-poky-linux/xserver-xf86-config-0.1-r9/xorg.conf is just from meta-intel/meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow/xorg.conf! This means I can't reproduce this bug. BTW: I used the same Poky Commit and Meta Commit as mentioned above by Jiajun. This is really weird... Maybe this bug only happens on autobuilder somehow??? As to Bug 1072, Tom, do you still remember the commit numbers of poky master/mete-intel based on which you reported the bug? Can you please use "bitbake xserver-xf86-config -c unpack -f" to verify the bug is reproducible? 13993 3 jiajun.xu 2011-05-26 06:46:30 +0000 (In reply to comment #2) > (In reply to comment #0) > > Tree/Branch: Poky/1.1_M1 > > Poky Commit: fc55b224caa3eeac4abda099ec9ed505db59fb28 > > Meta Branch: 1.1_M1 > > Meta Commit: 1b227f8ed2df529cc13f7169b0c08ff3d0f8c812 > Hi Jiajun, how did you know the meta commit 1b227f? The autobuilder's file > gitinfo only shows the commit number of poky master. > Dexuan, I could get both poky and meta-intel commit from http://autobuilder.pokylinux.org:8010/builders/emenlow. There will be several build task on the page. You could click hyperlink of each build id. Any by checking the build time (RC1 build is triggered on May 20th), we could find which build is what we want. In the build page, http://autobuilder.pokylinux.org:8010/builders/emenlow/builds/47, there are detailed information for both poky and meta-intel commit. 13994 4 jiajun.xu 2011-05-26 06:53:51 +0000 Update the title since blacksand could start X with live boot. And only crownbay-noemgd is tested since crownbay image build failed. 14005 5 dvhart 2011-05-26 15:18:11 +0000 Tom or Darren to look at ASAP and ask Dexuan to assist if not root-caused today or tomorrow. 14012 6 tom.zanussi 2011-05-26 15:40:42 +0000 (In reply to comment #2) > (In reply to comment #0) > > Tree/Branch: Poky/1.1_M1 > > Poky Commit: fc55b224caa3eeac4abda099ec9ed505db59fb28 > > Meta Branch: 1.1_M1 > > Meta Commit: 1b227f8ed2df529cc13f7169b0c08ff3d0f8c812 > Hi Jiajun, how did you know the meta commit 1b227f? The autobuilder's file > gitinfo only shows the commit number of poky master. > > (In reply to comment #1) > > Sounds like it could be a duplicate of 1072 (machine-specific xorg.confs not > > being picked up) e.g. crownbay shouldn't even be looking for module "intel". > Agree. > I checked the file core-image-sato-sdk-live-emenlow-20110521070906.hddimg.bz2 > and the file xorg.conf in it is from > meta/recipes-graphics/xorg-xserver/xserver-xf86-config/xorg.conf > rather than > meta-intel/meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow/xorg.conf. > I'm not sure what caused this, however, with MACHINE="emenlow", when I did > "bitbake xserver-xf86-config -c unpack -f", I found > tmp/work/emenlow-poky-linux/xserver-xf86-config-0.1-r9/xorg.conf is just from > meta-intel/meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config/emenlow/xorg.conf! > This means I can't reproduce this bug. > BTW: I used the same Poky Commit and Meta Commit as mentioned above by Jiajun. > This is really weird... Maybe this bug only happens on autobuilder somehow??? > > As to Bug 1072, Tom, do you still remember the commit numbers of poky > master/mete-intel based on which you reported the bug? Can you please use > "bitbake xserver-xf86-config -c unpack -f" to verify the bug is reproducible? I just updated bug 1072 with information that allows me to reproduce the xorg.conf problem. 14013 7 tom.zanussi 2011-05-26 16:15:46 +0000 bitbake xserver-xf86-config -c unpack -f for crownbay-noemgd with the named commits shows a correct xorg.conf. 14017 8 dexuan.cui 2011-05-26 19:09:34 +0000 (In reply to comment #7) > bitbake xserver-xf86-config -c unpack -f > for crownbay-noemgd > with the named commits shows a correct xorg.conf. But in bug 1072, doing the bitbake for sugarbay shows a wrong xorg.conf in your side. In my side, doing the bitbake for menlow and sugarbay both shows a correct xorg.conf. I'm trying to figure out why I can't reproduce the bug... 14019 9 tom.zanussi 2011-05-26 20:20:22 +0000 (In reply to comment #8) > (In reply to comment #7) > > bitbake xserver-xf86-config -c unpack -f > > for crownbay-noemgd > > with the named commits shows a correct xorg.conf. > > But in bug 1072, doing the bitbake for sugarbay shows a wrong xorg.conf in > your side. > > > In my side, doing the bitbake for menlow and sugarbay both shows a correct > xorg.conf. > > I'm trying to figure out why I can't reproduce the bug... Because I thought there was no problem with crownbay noemgd, I did a complete new build of core-image-sato-live assuming the xorg.conf would be correct, but checking the xorg.conf I see it's the wrong one again. I get this in xorg.conf: Section "Device" Identifier "Intel Graphics Driver" Driver "intel" EndSection When I should get this: Section "Device" Identifier "Generic VESA" Driver "vesa" EndSection The only difference I can see was that this was a fresh build of a whole image, where the other just built the package alone. In this case, bitbake -c cleanall xserver-xf86-config followed by bitbake xserver-xf86-config -c unpack -f still shows the problem 14021 10 dvhart 2011-05-26 21:13:46 +0000 Tom noticed that there was a difference between the ordering of the bbappend LOAD in the logs between a good and a bad unpack. In a good case it looks like this (using -DDDD): DEBUG: Appending .bbappend file /home/dvhart/source/poky.git/meta-yocto/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend to /home/dvhart/source/poky.git/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb DEBUG: BB /home/dvhart/source/poky.git/meta-yocto/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend: handle(data, include) DEBUG: LOAD /home/dvhart/source/poky.git/meta-yocto/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend DEBUG: Appending .bbappend file /home/dvhart/source/poky.git/layers/meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend to /home/dvhart/source/poky.git/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb DEBUG: BB /home/dvhart/source/poky.git/layers/meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend: handle(data, include) DEBUG: LOAD /home/dvhart/source/poky.git/layers/meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend Where the meta-crownbay bbappend is added last. In a bad unpack, it looks like this: DEBUG: Appending .bbappend file /usr/local/src/yocto/junk/meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.b\ bappend to /usr/local/src/yocto/junk/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb DEBUG: BB /usr/local/src/yocto/junk/meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend: handle(data, \ include) DEBUG: LOAD /usr/local/src/yocto/junk/meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend DEBUG: Appending .bbappend file /usr/local/src/yocto/junk/meta-yocto/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend to /us\ r/local/src/yocto/junk/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb DEBUG: BB /usr/local/src/yocto/junk/meta-yocto/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend: handle(data, include) DEBUG: LOAD /usr/local/src/yocto/junk/meta-yocto/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend Note that meta-yocto is added second. In each case, the priority of meta-yocto was 5 and the priority of meta-crownbay was 6. 14022 11 dvhart 2011-05-26 21:59:43 +0000 Apparently the pathnames for the layers impact the order in which they are loaded. If I setup symlinks to mirror tomz's setup, I can reproduce the bug: Good bblayers.conf: BBLAYERS = " \ /home/dvhart/source/poky.git/meta \ /home/dvhart/source/poky.git/meta-yocto \ /home/dvhart/source/poky.git/layers/meta-intel/meta-crownbay \ Bad bblayers.conf: BBLAYERS = " \ /usr/local/src/yocto/junk/meta \ /usr/local/src/yocto/junk/meta-yocto \ /usr/local/src/yocto/junk/meta-intel/meta-crownbay \ And note that these are indeed pointing to the same place: $ ls -la /usr/local/src/yocto/junk/ total 8 drwxr-xr-x 2 root root 4096 2011-05-26 21:55 . drwxr-xr-x 3 root root 4096 2011-05-26 21:52 .. lrwxrwxrwx 1 root root 33 2011-05-26 21:55 meta -> /home/dvhart/source/poky.git/meta lrwxrwxrwx 1 root root 46 2011-05-26 21:54 meta-intel -> /home/dvhart/source/poky.git/layers/meta-intel lrwxrwxrwx 1 root root 39 2011-05-26 21:53 meta-yocto -> /home/dvhart/source/poky.git/meta-yocto 14025 12 dvhart 2011-05-27 00:02:57 +0000 I've arrived at root cause. After some instrumenting (patch to be attached in case anyone is interested) I learned that the root of the problem is that cooker.py BBCooker.collect_bbfiles() doesn't take priority or bblayers.conf ordering into account when preparing the files lists. The most relevant bit follows: newfiles = set() for f in files: bb.plain("parsing %s" % f) if os.path.isdir(f): dirfiles = self.find_bbfiles(f) newfiles.update(dirfiles) else: globbed = glob.glob(f) if not globbed and os.path.exists(f): globbed = [f] newfiles.update(globbed) ... bb.plain("xserver-xf86-config files:") for f in newfiles: if f.count("xserver-xf86-config") > 0: bb.plain(" %s" % f) With the known good paths, this results in: xserver-xf86-config files: /home/dvhart/source/poky.git/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb /home/dvhart/source/poky.git/meta-yocto/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend /home/dvhart/source/poky.git/layers/meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend With the known bad paths, this results in: xserver-xf86-config files: /usr/local/src/yocto/junk/meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend /usr/local/src/yocto/junk/meta-yocto/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend /usr/local/src/yocto/junk/meta/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb Note that in the bad path, the meta recipe is last in the list (taking precedence over the other files). By using a python set type (which I gather is convenient for the bbmask mechanism) we lose any ordering that existed simply from the ordering of the layers in bblayers.conf. Consider the following: In [1]: a=set() In [2]: b=set() In [3]: a.add("a") In [4]: a.add("b") In [5]: a.add("c") In [6]: print list(a) ['a', 'c', 'b'] In [7]: b.add("z") In [8]: b.add("y") In [9]: b.add("x") In [10]: print list(b) ['y', 'x', 'z'] Notice the difference in output order versus input order. If you replace the letters with the layer paths, you get the same sort of result. A proper fix for this probably involves ensuring files are enumerated in layer priority order. 14026 13 168 dvhart 2011-05-27 00:07:41 +0000 Created attachment 168 dvhart's bitbake instrumentation patch Here is the instrumentation patch I used to track down the bbappend ordering issue in case it is of any use to anyone. 14027 14 dvhart 2011-05-27 00:08:22 +0000 Removing Blacksand and setting to All as this is a core bitbake issue and really not machine specific. 14054 15 richard.purdie 2011-05-27 10:23:18 +0000 Master has a fix for this: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=00c71132d5a326546bbb7fdf173995c76a9e9803 14055 16 sgw 2011-05-27 10:44:38 +0000 Commited to master and cherry-picked to M1 14057 17 dvhart 2011-05-27 10:56:54 +0000 Please note that this is a workaround. It makes it so the order of repositories are honored in bblayers.conf, but it does not address the missing layer priority ordering. I've opened a new bug for that: Bug 1125 14069 18 jiajun.xu 2011-05-31 01:55:50 +0000 Verify the bug with Yocto 1.1 M1 RC2 build, the bug is fixed. Detailed commit information: Tree/Branch: Poky/1.1_M1 Poky Commit: 4ff7af11ef69849ef9c16f585eae58ac920b222b Meta Branch: 1.1_M1 Meta Commit: fc719f0cd6530ce15148b4aa274f1644b461b298 168 2011-05-27 00:07:41 +0000 2011-05-27 00:07:41 +0000 dvhart's bitbake instrumentation patch bitbake-inst-dvhart.patch text/plain 3098 dvhart ZGlmZiAtLWdpdCBhL2JpdGJha2UvbGliL2JiL2NhY2hlLnB5IGIvYml0YmFrZS9saWIvYmIvY2Fj aGUucHkKaW5kZXggZDA4M2M1MS4uMTQ2MDdhNCAxMDA2NDQKLS0tIGEvYml0YmFrZS9saWIvYmIv Y2FjaGUucHkKKysrIGIvYml0YmFrZS9saWIvYmIvY2FjaGUucHkKQEAgLTUzMCw2ICs1MzAsMTMg QEAgY2xhc3MgQ2FjaGUob2JqZWN0KToKICAgICAgICAgdHJ5OgogICAgICAgICAgICAgaWYgYXBw ZW5kczoKICAgICAgICAgICAgICAgICBkYXRhLnNldFZhcignX19CQkFQUEVORCcsICIgIi5qb2lu KGFwcGVuZHMpLCBiYl9kYXRhKQorICAgICAgICAgICAgICAgIGJiLnBsYWluKCIqKioqKioqKioq KioqIF9fQkJBUFBFTkQgKioqKioqKioqKioqKioqKioiKQorICAgICAgICAgICAgICAgIGJiLnBs YWluKCJGSUxFOiAlcyIgJSBiYmZpbGVfbG9jKQorICAgICAgICAgICAgICAgIGJiLnBsYWluKCJS QVc6ICVzIiAlICIgIi5qb2luKGFwcGVuZHMpKQorICAgICAgICAgICAgICAgIGJiLnBsYWluKCJD YWxsIFN0YWNrOiIpCisgICAgICAgICAgICAgICAgaW1wb3J0IGluc3BlY3QKKyAgICAgICAgICAg ICAgICBiYi5wbGFpbigiIDw8ICIuam9pbihbaVszXSBmb3IgaSBpbiBpbnNwZWN0LnN0YWNrKClb MTotNF1dKSkKKyAgICAgICAgICAgICAgICBiYi5wbGFpbigiKioqKioqKioqKioqKiBFTkQgKioq KioqKioqKioqKioqKioiKQogICAgICAgICAgICAgYmJfZGF0YSA9IHBhcnNlLmhhbmRsZShiYmZp bGUsIGJiX2RhdGEpCiAgICAgICAgICAgICBpZiBjaGRpcl9iYWNrOgogICAgICAgICAgICAgICAg IG9zLmNoZGlyKG9sZHBhdGgpCmRpZmYgLS1naXQgYS9iaXRiYWtlL2xpYi9iYi9jb29rZXIucHkg Yi9iaXRiYWtlL2xpYi9iYi9jb29rZXIucHkKaW5kZXggYTFjZDRkNy4uM2IzODE4MiAxMDA2NDQK LS0tIGEvYml0YmFrZS9saWIvYmIvY29va2VyLnB5CisrKyBiL2JpdGJha2UvbGliL2JiL2Nvb2tl ci5weQpAQCAtOTM3LDEyICs5MzcsMTggQEAgY2xhc3MgQkJDb29rZXI6CiAgICAgICAgIGlmIG5v dCBsZW4oZmlsZXMpOgogICAgICAgICAgICAgZmlsZXMgPSBzZWxmLmdldF9iYmZpbGVzKCkKIAor ICAgICAgICBiYi5wbGFpbigiY29sbGVjdF9iYmZpbGVzIikKKyAgICAgICAgZm9yIGYgaW4gZmls ZXM6CisgICAgICAgICAgICBiYi5wbGFpbigiICAgICVzIiAlIGYpCisKICAgICAgICAgaWYgbm90 IGxlbihmaWxlcyk6CiAgICAgICAgICAgICBjb2xsZWN0bG9nLmVycm9yKCJubyByZWNpcGUgZmls ZXMgdG8gYnVpbGQsIGNoZWNrIHlvdXIgQkJQQVRIIGFuZCBCQkZJTEVTPyIpCiAgICAgICAgICAg ICBiYi5ldmVudC5maXJlKENvb2tlckV4aXQoKSwgc2VsZi5jb25maWd1cmF0aW9uLmV2ZW50X2Rh dGEpCiAKKyAgICAgICAgYmIucGxhaW4oIkdlbmVyYXRpbmcgbmV3ZmlsZXM6IikKICAgICAgICAg bmV3ZmlsZXMgPSBzZXQoKQogICAgICAgICBmb3IgZiBpbiBmaWxlczoKKyAgICAgICAgICAgIGJi LnBsYWluKCJwYXJzaW5nICVzIiAlIGYpCiAgICAgICAgICAgICBpZiBvcy5wYXRoLmlzZGlyKGYp OgogICAgICAgICAgICAgICAgIGRpcmZpbGVzID0gc2VsZi5maW5kX2JiZmlsZXMoZikKICAgICAg ICAgICAgICAgICBuZXdmaWxlcy51cGRhdGUoZGlyZmlsZXMpCkBAIC05NjMsNyArOTY5LDEwIEBA IGNsYXNzIEJCQ29va2VyOgogCiAgICAgICAgIGJiZmlsZXMgPSBbXQogICAgICAgICBiYmFwcGVu ZCA9IFtdCisgICAgICAgIGJiLnBsYWluKCJ4c2VydmVyLXhmODYtY29uZmlnIGZpbGVzOiIpCiAg ICAgICAgIGZvciBmIGluIG5ld2ZpbGVzOgorICAgICAgICAgICAgaWYgZi5jb3VudCgieHNlcnZl ci14Zjg2LWNvbmZpZyIpID4gMDoKKyAgICAgICAgICAgICAgICBiYi5wbGFpbigiICAlcyIgJSBm KQogICAgICAgICAgICAgaWYgYmJtYXNrIGFuZCBiYm1hc2tfY29tcGlsZWQuc2VhcmNoKGYpOgog ICAgICAgICAgICAgICAgIGNvbGxlY3Rsb2cuZGVidWcoMSwgInNraXBwaW5nIG1hc2tlZCBmaWxl ICVzIiwgZikKICAgICAgICAgICAgICAgICBtYXNrZWQgKz0gMQpAQCAtOTc1LDYgKzk4NCwxMSBA QCBjbGFzcyBCQkNvb2tlcjoKICAgICAgICAgICAgIGVsc2U6CiAgICAgICAgICAgICAgICAgY29s bGVjdGxvZy5kZWJ1ZygxLCAic2tpcHBpbmcgJXM6IHVua25vd24gZmlsZSBleHRlbnNpb24iLCBm KQogCisgICAgICAgIGJiLnBsYWluKCJ4c2VydmVyLXhmODYtY29uZmlnIGJiYXBwZW5kIGZpbGVz OiIpCisgICAgICAgIGZvciBmIGluIGJiYXBwZW5kOgorICAgICAgICAgICAgaWYgZi5jb3VudCgi eHNlcnZlci14Zjg2LWNvbmZpZyIpID4gMDoKKyAgICAgICAgICAgICAgICBiYi5wbGFpbigiICAl cyIgJSBmKQorCiAgICAgICAgICMgQnVpbGQgYSBsaXN0IG9mIC5iYmFwcGVuZCBmaWxlcyBmb3Ig ZWFjaCAuYmIgZmlsZQogICAgICAgICBmb3IgZiBpbiBiYmFwcGVuZDoKICAgICAgICAgICAgIGJh c2UgPSBvcy5wYXRoLmJhc2VuYW1lKGYpLnJlcGxhY2UoJy5iYmFwcGVuZCcsICcuYmInKQpkaWZm IC0tZ2l0IGEvYml0YmFrZS9saWIvYmIvcnVucXVldWUucHkgYi9iaXRiYWtlL2xpYi9iYi9ydW5x dWV1ZS5weQppbmRleCA2Y2ExNGVjLi45Y2M3ZTNjIDEwMDY0NAotLS0gYS9iaXRiYWtlL2xpYi9i Yi9ydW5xdWV1ZS5weQorKysgYi9iaXRiYWtlL2xpYi9iYi9ydW5xdWV1ZS5weQpAQCAtMTEwNyw2 ICsxMTA3LDkgQEAgY2xhc3MgUnVuUXVldWVFeGVjdXRlOgogICAgICAgICAgICAgb3MuZHVwMihu ZXdzaSwgc3lzLnN0ZGluLmZpbGVubygpKQogCiAKKyAgICAgICAgICAgIGJiLnBsYWluKCJmb3Jr X29mZl90YXNrOiIpCisgICAgICAgICAgICBiYi5wbGFpbigiICAgICAgIGZuOiAlcyIgJSBmbikK KyAgICAgICAgICAgIGJiLnBsYWluKCIgIGFwcGVuZHM6ICVzIiAlIHNlbGYuY29va2VyLmdldF9m aWxlX2FwcGVuZHMoZm4pKQogICAgICAgICAgICAgdGhlX2RhdGEgPSBiYi5jYWNoZS5DYWNoZS5s b2FkRGF0YUZ1bGwoZm4sIHNlbGYuY29va2VyLmdldF9maWxlX2FwcGVuZHMoZm4pLCBzZWxmLmNv b2tlci5jb25maWd1cmF0aW9uLmRhdGEpCiAKICAgICAgICAgICAgIGVudjIgPSBiYi5kYXRhLmV4 cG9ydF92YXJzKHRoZV9kYXRhKQo=