113298 2005-11-22 15:52 0000 man fails due to missing shadow for adding users/groups 2006-06-09 13:12:32 0000 1 1 1 Unclassified Gentoo Release Media Everything unspecified All Linux RESOLVED DUPLICATE P2 blocker --- 119737 1 Tiger683@buerotiger.de base-system@gentoo.org andreas.haak@emsisoft.com cron-bugs@gentoo.org gopal@gopalarathnam.com hollow@gentoo.org jakub@gentoo.org jonas@artavatar.org maarten@fmwb.org release@gentoo.org ronald@hummelink.net siryes@gmail.com solar@gentoo.org yen@telenet.be zlin@gentoo.org Tiger683@buerotiger.de 2005-11-22 15:52:31 0000 Migration between different CHOSTs during a stage 1/2 installation when doing emerge -e system. This bug seems to affect mainly autoconf-2.59 and cronbase. Autoconf fails because of Perl not being recompiled before it (Data::Dumper module is not found) and cronbase because there is no functional Shadow for adding the user/group. To work around this bug, a change in dependencies should be done, so that the order of affected packages is : perl -> shadow -> cronbase The respective dependencies get pulled in in right order too. Reproducible: Always Steps to Reproduce: 1.decide to make a stage 1/2 installation 2.change CHOST value 3.emerge -e system (evtl. after successful bootstrap if stage1 install) Actual Results: emerge -e system breaks at cronbase. even if this one gets injected externally with ROOT="..." set, autoconf-2.59 will fail because of not-found perl module Expected Results: all steps from stage1 throughout the installation until a reboot should run flawlessly roger55@gentoo.org 2005-11-22 16:07:59 0000 *** Bug 113299 has been marked as a duplicate of this bug. *** wolf31o2@gentoo.org 2005-11-23 04:38:21 0000 No need to CC me when I told you where to assign it. Also, no need for a blocker... well... pretty much ever. The only time we consider something a "blocker" is when it means "Oh dear God, we need to roll out a new release because of this *NOW*" type of thing. I'll get to this today. I honestly didn't have much time to work on Gentoo last night. Tiger683@buerotiger.de 2005-11-23 04:45:18 0000 Sorry for this, won't happen again... Tiger683@buerotiger.de 2005-11-23 06:12:07 0000 (In reply to comment #0) Apparently, the problem is a missing dependency in the depgraph concerning dependencies of cronbase, or more precisely eutils. Reasons for NOT adding shadow to eutils dependencies is more or less elaborated in bug #94745, see comment 5 + 6... I think cronbase maintainer should be bugged to add the dep, as this might solve all problems regarding CHOST issue with stage1/2 installs, life of releng people would certainly get a little less stressful too. I didn't CC no one this time, someone more appropriate should do it ;) Tiger683@buerotiger.de 2005-11-23 09:54:41 0000 Created an attachment (id=73440) emerge info This is emerge info from my main system, although it is not built upon the stages i have tested the above behaviours on. The interesting thing might be my catalyst version: dev-util/catalyst-2.0_pre20051122 wolf31o2@gentoo.org 2005-11-23 11:12:56 0000 I'm currently looking at implimenting a eusergroup eclass that includes enewuser and enewgroup (along with a couple helper functions). What this would do is allow us to make *that* eclass DEPEND on shadow (on Linux) and work around the problems in bug #94745 by side-stepping it. wolf31o2@gentoo.org 2006-01-17 04:08:34 0000 I've upgraded this to a blocker since some fix is required for our release to build properly and we are nearing our snapshot date. vapier@gentoo.org 2006-01-17 06:12:37 0000 or you could simply add shadow to packages.build and be done with it wolf31o2@gentoo.org 2006-01-17 06:35:08 0000 Except adding shadow breaks stage 1 and stage2 building, so isn't a viable solution, as I stated last time you brought it up. It also makes it impossible to build a set of default-linux stages without USE=pam... pylon@gentoo.org 2006-01-18 10:55:23 0000 (In reply to comment #9) > to build a set of default-linux stages without USE=pam... I have pam set in the generic ppc-profile. But it breaks as well. wolf31o2@gentoo.org 2006-01-20 11:59:25 0000 Testing results: Test #1 (shadow in packages.build and blockers removed) # grep shadow profiles/default-linux/packages.build # While shadow could be in here, it breaks stage 1 and stage 2 building for the sys-apps/shadow # grep pam-login sys-apps/shadow/shadow-4.0.7-r4.ebuild !pam? ( !build? ( !bootstrap? ( !sys-apps/pam-login ) ) ) # We moved /etc/pam.d/login to pam-login PDEPEND="pam? ( >=sys-apps/pam-login-3.17 )" # These is now shipped with pam-login, and login # pam-login now. >>> md5 files ;-) files/README >>> md5 files ;-) files/run-crons-0.2.1 * Adding group 'cron' to your system ... * - Groupid: 16 /usr/portage/eclass/eutils.eclass: line 735: groupadd: command not found !!! ERROR: sys-process/cronbase-0.3.2 failed. !!! Function enewgroup, Line 735, Exitcode 127 !!! enewgroup failed !!! If you need support, post the topmost build error, NOT this status message. !!! catalyst: run script failed. This is when it gets to building stage3. Test #2 (shadow in packages.build) # grep shadow profiles/default-linux/packages.build # While shadow could be in here, it breaks stage 1 and stage 2 building for the sys-apps/shadow # grep pam-login sys-apps/shadow/shadow-4.0.7-r4.ebuild !pam? ( !sys-apps/pam-login ) # We moved /etc/pam.d/login to pam-login PDEPEND="pam? ( >=sys-apps/pam-login-3.17 )" # These is now shipped with pam-login, and login # pam-login now. Calculating dependencies ...done! !!! Error: the sys-apps/pam-login package conflicts with another package. !!! both can't be installed on the same system together. !!! Please use 'emerge --pretend' to determine blockers. !!! catalyst: run script failed. This is building a stage1. wolf31o2@gentoo.org 2006-01-21 14:47:28 0000 Possible solution: #1: Add pam to STAGE1_USE in *all* pam-enabled 2006.0 profiles #2: Add sys-apps/shadow to default-linux/packages.build This has been verified to work on x86. Currently testing on amd64/ppc... wolf31o2@gentoo.org 2006-01-22 06:17:14 0000 This also fixes amd64/ppc... I've added pam to STAGE1_USE on alpha, amd64, ppc, ppc64, sparc, and x86 for the 2006.0 profiles. The rest of you need to make yourself a 2006.0 profile and make this change. kumba@gentoo.org 2006-01-22 11:09:11 0000 mips done wolf31o2@gentoo.org 2006-01-22 15:55:06 0000 I did s390 since there was already a 2006.0 profile... wolf31o2@gentoo.org 2006-01-25 05:42:02 0000 Apparently adding PAM to stage1 is a bad thing, so I'm adding solar to CC since he was working on a solution to this that doesn't involve PAM in stage1. I am removing arches from CC since we might not need to do this. I'll add them back if it ends up being necessary in the end or if another solution requires their assistance. wolf31o2@gentoo.org 2006-02-06 08:49:08 0000 *** Bug 121807 has been marked as a duplicate of this bug. *** wolf31o2@gentoo.org 2006-02-06 08:50:40 0000 OK. I have resolved this in my snapshots with two changes. First, I have removed sys-process/cronbase from RDEPEND on man, since it wasn't necessary. Second, I have added a patch to baselayout-1.11.14-r3 in my snapshot that adds back the man user and group. After these two changes, stage3 builds successfully (without pam in STAGE1_USE) on all arches. wolf31o2@gentoo.org 2006-02-14 08:35:19 0000 Created an attachment (id=79772) baselayout-1.11.14-users.patch This patch resolves this issue for me. solar@gentoo.org 2006-02-14 09:23:33 0000 Chris should this bug be reassigned to spanky/baselayout/base-system now? wolf31o2@gentoo.org 2006-02-14 09:40:38 0000 I would say so. I'm keeping release on CC, though, since it'll affect anyone trying to build from stage1, so I'm sure we'll get *lots* of bugs on this if it isn't fixed in the tree by the time 2006.0 rolls out. vapier@gentoo.org 2006-02-14 09:51:57 0000 that's the point of the dupe gustavoz@gentoo.org 2006-03-17 06:02:07 0000 Anything new about this? Stages can't be built with a current snapshot without tweaking it. vapier@gentoo.org 2006-04-07 19:38:19 0000 *** Bug 127157 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-04-08 09:02:41 0000 *** Bug 129255 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-04-14 08:18:14 0000 *** Bug 129951 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-04-14 08:21:10 0000 *** Bug 128999 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-04-14 08:38:05 0000 Is there still any issue with adding shadow dependency back to eutils.eclass (where is really belongs), once the new shadow with re-integrated pam-login is marked stable? (Not that I'd notice any significant benefit wrt punting of various pretty much essential groups/users like cron/sshd/man from baselayout in the first place...) wolf31o2@gentoo.org 2006-04-17 15:03:20 0000 shadow inherits eutils, so it can't be a dependency of eutils... jakub@gentoo.org 2006-04-17 15:13:27 0000 (In reply to comment #29) > shadow inherits eutils, so it can't be a dependency of eutils... It can with a little hack... MY_PN="shadow" DEPEND="!bootstrap? ( sys-devel/patch )" RDEPEND="" if [[ "${PN}" != "${MY_PN}" ]]; then DEPEND="${DEPEND} sys-apps/shadow" RDEPEND="${RDEPEND}" fi wolf31o2@gentoo.org 2006-04-18 08:22:32 0000 As soon as you can prove to me that it won't cause more trouble than it is worth when trying to build stages via catalyst, I'll do it. However, I can guarantee you that this will cause circular dependencies and generally be more trouble than it is worth. jakub@gentoo.org 2006-04-18 08:34:54 0000 Shrug. If the above produces circular dependencies, then portage is broken... If that's not an acceptable solution, then I'd suggest re-adding cron/sshd/man back to baselayout and think twice before punting them again just for the sake of saving a few "redundant" lines in /etc/{passwd,group}. solar@gentoo.org 2006-04-18 08:40:46 0000 (In reply to comment #32) > Shrug. If the above produces circular dependencies, then portage is broken... Circular dependencies are just that. portage broken or not.. A circle is still round. > If that's not an acceptable solution, then I'd suggest re-adding cron/sshd/man > back to baselayout and think twice before punting them again just for the sake > of saving a few "redundant" lines in /etc/{passwd,group}. Right this is the only real solution to the problem. wolf31o2@gentoo.org 2006-04-18 14:55:34 0000 The only thing that is required to be added back in man user/group. That is because shadow will come in after man, but before openssh/cronbase. As I said, the patch above worked perfectly for the 2006.0 release. jakub@gentoo.org 2006-05-10 14:10:33 0000 *** Bug 132947 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-05-14 03:02:12 0000 *** Bug 133281 has been marked as a duplicate of this bug. *** solar@gentoo.org 2006-05-28 18:36:30 0000 This is a formal vote for the solution presented by Chris in comment #34, me in #33 and others via IRC. Add man back to user/group as needed and lose the dep so this bug wont hold up releng or others building feom the lowe levels of gentoo without adding any new deps. In addition I vote for making the change within the next few days. kumba@gentoo.org 2006-05-28 18:39:52 0000 Seconded. This just halted my 2006.1-pre stage run for mips, so I wanna squish it. gustavoz@gentoo.org 2006-05-29 10:38:45 0000 +1 i've been patching this for ages now to build QA stuff and it's quite bothersome. gmsoft@gentoo.org 2006-05-29 10:51:05 0000 +1 I'm for it. weeve@gentoo.org 2006-05-29 11:24:40 0000 +1 from me as well (as the supposed SPARC basesystem guy). vapier@gentoo.org 2006-06-07 06:15:53 0000 formal vote ? you just made that up adding users back into baselayout ignores problems, it doesnt fix them the only real fix is having portage create the users instead of relying on packages such as shadow being installed antarus@gentoo.org 2006-06-07 06:25:21 0000 (In reply to comment #42) > formal vote ? you just made that up > > adding users back into baselayout ignores problems, it doesnt fix them > > the only real fix is having portage create the users instead of relying on > packages such as shadow being installed > while i agree with you on principal, this bug is holding people up. We have a SoC project for GLEP 27, perhaps we can provide a module for this situation. For now though, if you don't have a workable solution, I can't see a reason to leave it 'broken'; ie it blocks legitimate work for a bunch of other projects. solar@gentoo.org 2006-06-07 06:32:21 0000 (In reply to comment #42) > formal vote ? you just made that up > > adding users back into baselayout ignores problems, it doesnt fix them > > the only real fix is having portage create the users instead of relying on > packages such as shadow being installed man is a user on every system. There is no reason to not really have it there cept maybe on uclibc systems where noman might be set. Problem is this is blocking building from stage1 (comment #9) correctly and forcing shadow where it was not forced before is a worse solution than a one liner returning old behavior. If you have a creative way to add users which does not rely on shadow then I think all of us are all ears. vapier@gentoo.org 2006-06-07 09:16:25 0000 the man account serves no purpose when the system has no man functionality installed as i said, moving the logic to portage negates the need for any accounting utilities to be preinstalled agaffney@gentoo.org 2006-06-07 09:18:59 0000 Feel free to remove the 'man' user/group once that logic has been moved to portage and is shown to be stable (and work with ${ROOT}!) :) kumba@gentoo.org 2006-06-07 21:23:36 0000 Portage-2.1 is in feature freeze right now, so even if someone cooked up that kind of logic, it would be of no use because it would not be able to make the snapshot, so the temp solution for now is the one-line addition. Maybe said logic can be drafted and put into portage before 2007.0 rolls around (it can't be that hard -- anyone even drafted up pseudo-code or something for it?), and we can get rid of this change. But for 2006.1 to work well, we need this change. vapier@gentoo.org 2006-06-09 07:26:45 0000 *** This bug has been marked as a duplicate of 53269 *** antarus@gentoo.org 2006-06-09 08:36:58 0000 When glep 27 is done, this is fixed, fix your shit now and we can fix it later at the end of the summer. Don't go creating problems when no solution exists. vapier@gentoo.org 2006-06-09 13:12:32 0000 instead of being a jackass why dont you read the backlog baselayout isnt broken people want to add users back in to baselayout to ignore the underlying issue uberlord *already added the user back in to baselayout* the problem reported here *no longer shows up because the hacks have been added back into portage* no go back to doing something useful instead of re-opening bugs you havent been following *** This bug has been marked as a duplicate of 53269 *** 73440 2005-11-23 09:54 0000 emerge info emerge-info text/plain UG9ydGFnZSAyLjAuNTNfcmM3IChkZWZhdWx0LWxpbnV4L3g4Ni8yMDA1LjEsIGdjYy00LjAuMi0y MDA1MTAwNywKZ2xpYmMtMi4zLjUuMjAwNTEwMTktcjAsIDIuNi4xNC1uaXRybzIgaTY4NikKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KU3lzdGVtIHVuYW1lOiAyLjYuMTQtbml0cm8yIGk2ODYgQU1EIEF0aGxvbih0bSkgWFAg MzEwMCsKR2VudG9vIEJhc2UgU3lzdGVtIHZlcnNpb24gMS4xMi4wX3ByZTEwCmNjYWNoZSB2ZXJz aW9uIDIuNCBbZW5hYmxlZF0KZGV2LWxhbmcvcHl0aG9uOiAgICAgMi4zLjUsIDIuNC4yCnN5cy1h cHBzL3NhbmRib3g6ICAgIDEuMi4xMwpzeXMtZGV2ZWwvYXV0b2NvbmY6ICAyLjEzLCAyLjU5LXI3 CnN5cy1kZXZlbC9hdXRvbWFrZTogIDEuNF9wNiwgMS41LCAxLjYuMywgMS43LjktcjEsIDEuOC41 LXIzLCAxLjkuNi1yMQpzeXMtZGV2ZWwvYmludXRpbHM6ICAyLjE2LjEKc3lzLWRldmVsL2xpYnRv b2w6ICAgMS41LjIwCnZpcnR1YWwvb3MtaGVhZGVyczogIDIuNi4xMS1yMgpBQ0NFUFRfS0VZV09S RFM9Ing4NiB+eDg2IgpBVVRPQ0xFQU49InllcyIKQ0hPU1Q9Imk2ODYtcGMtbGludXgtZ251IgpD RkxBR1M9Ii1PMiAtbWFyY2g9YXRobG9uLXhwIC1tdHVuZT1hdGhsb24teHAgLW1tbXggLW0zZG5v dyAtbXNzZSAtcGlwZSAtZm9taXQtZnJhbWUtcG9pbnRlciIKQ09ORklHX1BST1RFQ1Q9Ii9ldGMg L3Vzci9rZGUvMi9zaGFyZS9jb25maWcgL3Vzci9rZGUvMy9zaGFyZS9jb25maWcgL3Vzci9rZGUv ZGV2ZWwvZW52IC91c3Iva2RlL2RldmVsL3NoYXJlL2NvbmZpZyAvdXNyL2tkZS9kZXZlbC9zaHV0 ZG93biAvdXNyL2xpYi9YMTEveGtiIC91c3Ivc2hhcmUvY29uZmlnIC92YXIvcW1haWwvY29udHJv bCIKQ09ORklHX1BST1RFQ1RfTUFTSz0iL2V0Yy9nY29uZiAvZXRjL3Rlcm1pbmZvIC9ldGMvZW52 LmQiCkNYWEZMQUdTPSItTzIgLW1hcmNoPWF0aGxvbi14cCAtbXR1bmU9YXRobG9uLXhwIC1tbW14 IC1tM2Rub3cgLW1zc2UgLXBpcGUgLWZvbWl0LWZyYW1lLXBvaW50ZXIiCkRJU1RESVI9Ii91c3Iv cG9ydGFnZS9kaXN0ZmlsZXMiCkZFQVRVUkVTPSJhdXRvY29uZmlnIGNjYWNoZSBkaXN0bG9ja3Mg c2FuZGJveCBzZnBlcm1zIHN0cmljdCB1c2VycHJpdiB1c2Vyc2FuZGJveCIKR0VOVE9PX01JUlJP UlM9ImZ0cDovL2Z0cC50dS1jbGF1c3RoYWwuZGUvcHViL2xpbnV4L2dlbnRvbyBodHRwOi8vbWly cm9ycy5zZWMuaW5mb3JtYXRpay50dS1kYXJtc3RhZHQuZGUvZ2VudG9vIGZ0cDovL2Z0cC1zdHVk LmZodC1lc3NsaW5nZW4uZGUvcHViL01pcnJvcnMvZ2VudG9vIGh0dHA6Ly9nZW50b28ub3N1b3Ns Lm9yZyBodHRwOi8vd3d3LmliaWJsaW8ub3JnL3B1Yi9MaW51eC9kaXN0cmlidXRpb25zL2dlbnRv byIKTERGTEFHUz0iLVdsLC1PMSIKTElOR1VBUz0iZGUgZW5fR0IiCk1BS0VPUFRTPSItajIiClBL R0RJUj0iL3Vzci9wb3J0YWdlL3BhY2thZ2VzIgpQT1JUQUdFX1RNUERJUj0iL3Zhci90bXAiClBP UlRESVI9Ii91c3IvcG9ydGFnZSIKUE9SVERJUl9PVkVSTEFZPSIvdXNyL2xvY2FsL3BvcnRhZ2Ui ClNZTkM9InJzeW5jOi8vcnN5bmMuZ2VudG9vLm9yZy9nZW50b28tcG9ydGFnZSIKVVNFPSJ4ODYg M2Rub3cgWCBhNTIgYWFjIGFjbCBhY3BpIGFsc2EgYXBhY2hlMiBhcG0gYXVkaW9maWxlIGF2aSBi YXNoLWNvbXBsZXRpb24gYmVya2RiIGJpdG1hcC1mb250cyBiemlwMiBjYWlybyBjZHBhcmFub2lh IGNkciBjcnlwdCBjdHlwZSBjdXBzIGN1cmwgZGJ1cyBkZ2EgZGlvIGRpcmVjdGZiIGRpdng0bGlu dXggZHJpIGR2ZCBkdmRyZWFkIGVkcyBlbWJvc3MgZW5jb2RlIGV2YXMgZXhpZiBleHBhdCBmYW0g ZmZtcGVnIGZsYWMgZm9vbWF0aWNkYiBmb3J0cmFuIGZ0cCBnZGJtIGdnaSBnaWYgZ2xpYmMtb21p dGZwIGdsdXQgZ21wIGdub21lIGdwbSBnc3RyZWFtZXIgZ3RrIGd0azIgZ3RraHRtbCBoYWwgaWRu IGltYWdlbWFnaWNrIGltbGliIGphdmEgamF2YXNjcmlwdCBqaWtlcyBqcGVnIGp1bml0IGtkZSBs Y21zIGxpYmcrKyBsaWJ3d3cgbG1fc2Vuc29ycyBtYWQgbWhhc2ggbWlrbW9kIG1pbWUgbW1hcCBt bXggbW5nIG1vdGlmIG1wMyBtcGVnIG1wZnIgbXBpIG5jdXJzZXMgbmxzIG5vY2QgbnB0bCBucHRs b25seSBvZmZlbnNpdmUgb2dnIG9nZ3ZvcmJpcyBvcGVuYWwgb3BlbmdsIHBhbSBwY250bCBwY3Jl IHBkZmxpYiBwZXJsIHBocCBwbmcgcG9ydGF1ZGlvIHBvc2l4IHB5dGhvbiBxdCBxdWlja3RpbWUg cmVhZGxpbmUgc2FzbCBzZGwgc2hhcmVkbWVtIHNvY2tzNSBzcGVsbCBzcWxpdGUgc3NlIHNzbCBz dmdhIHN5bWxpbmsgc3lzdmlwYyBzemlwIHRjbHRrIHRjcGQgdGhlb3JhIHRocmVhZHMgdGlmZiB0 cnVldHlwZSB0cnVldHlwZS1mb250cyB0eXBlMS1mb250cyB1ZGV2IHVuaWNvZGUgdXNiIHVzZXJs b2NhbGVzIHZjZCB2b3JiaXMgd2luMzJjb2RlY3Mgd3h3aW5kb3dzIHhpbmUgeG1sMiB4bW1zIHhw bSB4diB4dmlkIHpsaWIgbGluZ3Vhc19kZSBsaW5ndWFzX2VuX0dCIHVzZXJsYW5kX0dOVSBrZXJu ZWxfbGludXggZWxpYmNfZ2xpYmMiClVuc2V0OiAgQVNGTEFHUywgQ1RBUkdFVCwgTEFORywgTENf QUxMCg== 79772 2006-02-14 08:35 0000 baselayout-1.11.14-users.patch baselayout-1.11.14-users.patch text/plain ZGlmZiAtdXJOIHJjLXNjcmlwdHMtMS42LjE0Lm9yaWcvZXRjL2dyb3VwIHJjLXNjcmlwdHMtMS42 LjE0L2V0Yy9ncm91cAotLS0gcmMtc2NyaXB0cy0xLjYuMTQub3JpZy9ldGMvZ3JvdXAJMjAwNi0w Mi0wMSAwOTowNjo1MS4wMDAwMDAwMDAgLTA1MDAKKysrIHJjLXNjcmlwdHMtMS42LjE0L2V0Yy9n cm91cAkyMDA2LTAyLTAxIDA5OjE4OjQyLjAwMDAwMDAwMCAtMDUwMApAQCAtMTMsNiArMTMsNyBA QAogbWFpbDo6MTI6bWFpbAogbmV3czo6MTM6bmV3cwogdXVjcDo6MTQ6dXVjcAorbWFuOjoxNTpt YW4KIGNvbnNvbGU6OjE3OgogYXVkaW86OjE4OgogY2Ryb206OjE5OgpkaWZmIC11ck4gcmMtc2Ny aXB0cy0xLjYuMTQub3JpZy9ldGMvcGFzc3dkIHJjLXNjcmlwdHMtMS42LjE0L2V0Yy9wYXNzd2QK LS0tIHJjLXNjcmlwdHMtMS42LjE0Lm9yaWcvZXRjL3Bhc3N3ZAkyMDA2LTAyLTAxIDA5OjA2OjUx LjAwMDAwMDAwMCAtMDUwMAorKysgcmMtc2NyaXB0cy0xLjYuMTQvZXRjL3Bhc3N3ZAkyMDA2LTAy LTAxIDA5OjE4OjQ5LjAwMDAwMDAwMCAtMDUwMApAQCAtMTAsNiArMTAsNyBAQAogbmV3czp4Ojk6 MTM6bmV3czovdXNyL2xpYi9uZXdzOi9iaW4vZmFsc2UKIHV1Y3A6eDoxMDoxNDp1dWNwOi92YXIv c3Bvb2wvdXVjcHB1YmxpYzovYmluL2ZhbHNlCiBvcGVyYXRvcjp4OjExOjA6b3BlcmF0b3I6L3Jv b3Q6L2Jpbi9iYXNoCittYW46eDoxMzoxNTptYW46L3Vzci9zaGFyZS9tYW46L2Jpbi9mYWxzZQog cG9zdG1hc3Rlcjp4OjE0OjEyOnBvc3RtYXN0ZXI6L3Zhci9zcG9vbC9tYWlsOi9iaW4vZmFsc2UK IHBvc3RncmVzOng6NzA6NzA6Oi92YXIvbGliL3Bvc3RncmVzcWw6L2Jpbi9iYXNoCiBudXQ6eDo4 NDo4NDpudXQ6L3Zhci9zdGF0ZS9udXQ6L2Jpbi9mYWxzZQo=