From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id CCvqI1xt72EkIgEAgWs5BA (envelope-from ) for ; Tue, 25 Jan 2022 04:24:12 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id EGBvIFxt72HrFQEAauVa8A (envelope-from ) for ; Tue, 25 Jan 2022 04:24:12 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CB46A32ADC for ; Tue, 25 Jan 2022 04:24:11 +0100 (CET) Received: from localhost ([::1]:37918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCCRG-0003SB-W0 for larch@yhetil.org; Mon, 24 Jan 2022 22:24:11 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45302) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCCR8-0003Rn-R1 for bug-guix@gnu.org; Mon, 24 Jan 2022 22:24:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:53594) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nCCR8-0000OG-HE for bug-guix@gnu.org; Mon, 24 Jan 2022 22:24:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nCCR8-0004ZD-Ak for bug-guix@gnu.org; Mon, 24 Jan 2022 22:24:02 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#53406: union-build incorrectly handles grafts Resent-From: John Kehayias Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 25 Jan 2022 03:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53406 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 53406@debbugs.gnu.org Received: via spool by 53406-submit@debbugs.gnu.org id=B53406.164308098317479 (code B ref 53406); Tue, 25 Jan 2022 03:24:02 +0000 Received: (at 53406) by debbugs.gnu.org; 25 Jan 2022 03:23:03 +0000 Received: from localhost ([127.0.0.1]:46497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCCQ5-0004XC-Bg for submit@debbugs.gnu.org; Mon, 24 Jan 2022 22:23:03 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:26213) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCCQ0-0004Wx-Uo for 53406@debbugs.gnu.org; Mon, 24 Jan 2022 22:22:56 -0500 Date: Tue, 25 Jan 2022 03:22:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1643080965; bh=c+cJuA84v9pAyxm9kRhFnVHPeWwsuW8axwE/pBTAvQA=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc; b=xUTl/xsw/iUWwOFcK41ZgKMjgFbXEKxp002MnZ1j4fxrY0EQvYnJBwvGjktw+ESVC ac519uRmfEBC1yedKY/yKEETFXNbLQsSm+oj899hl+YcftmvJZjjUIiOhoqxRrkZnO HKVrIwvQoa3XqJRotO5q0ETwxYGo2SC5AoRUdcukTNmLsYZlRRMfZWxV9/jijFI3JA GU0/LVSAdi2jgz/OZWgzKFObofULFnSMUBzm4sTrvcseTvY6XOp0NIiWCaU0FhKhE+ pr8lt3uSQsxAAMsDjdjFfa3T1k1VhbRoFywXlSMx39jJWCMjbkwPrucin3QETRdqQ8 BR111jrwuWPGA== Message-ID: In-Reply-To: <878rv5ushp.fsf@gnu.org> References: <878rv5ushp.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_hzGkhNMlchRq0mtQZRmqN67CjV1Rly5LI1bLHcO4d84" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" Reply-to: John Kehayias X-ACL-Warn: , John Kehayias From: John Kehayias via Bug reports for GNU Guix X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1643081052; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=c+cJuA84v9pAyxm9kRhFnVHPeWwsuW8axwE/pBTAvQA=; b=SaiGvwja3y7IsFTQgoa/W1FqkjCYj8gpqAmi5RyVJnfXR2mEyYpZojBGmGvqMAZfBxK+aA 5DlJuD2BbELLHAwRtirt5wBkxD/fmqhRX90l7tDsSd0rumkVRipEbChrCqCzDGQyPYLsqo i+IrbmEzJyh2kNiDLHADXL/pWvze/bLp2mrWD1nUnPnzn3ylm3iX0UAvkON8qWDnTn3gtT Om0qHKJpNk5l3v/v/zb23eHejZLVCToBenT7rwtWpxdIbRAAc0M4bZphyc6PFIwQh2KPn3 L8A9Stxxg+v22c+i4w4nANBARXQskiNSNpZtxAsVoiGtpqqjskgO4ECt0ZYWHQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643081052; a=rsa-sha256; cv=none; b=Dgq+P0Dl8yUlMz2ATd8dTFxXs6dLLvYZy/fURic7pYFS0HwwS5EOCTjG3Ic95N3GQ/nBk0 79Stknv9ME0DVLyPeRyrW8Llwd1RTyn1OnAF4EnQ1TAWOo3+zCZagCzra0GSMyl3MZsj+p pE6aY+SLWiFcXgrTW2DtD+lZP5+xhxYNB3nCJqq5fsisAymm0bkaza7qdoedUXsy7Z9BuM raMTjpgPfUCOfXOBhWCX6gAF1DLmzLKQKjoulAKZ3K8rRCdhRKckovpVzNBaQF50lXvQVH KJD9h7yy87dmdP4nRAY6rt7KR8eFE+kdxai96RuysTeFVTK/rWaKEHfPYk1+1g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=protonmail.com header.s=protonmail2 header.b="xUTl/xsw"; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.33 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=protonmail.com header.s=protonmail2 header.b="xUTl/xsw"; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: CB46A32ADC X-Spam-Score: -4.33 X-Migadu-Scanner: scn0.migadu.com X-TUID: yy+qgyxln93r This is a multi-part message in MIME format. --b1_hzGkhNMlchRq0mtQZRmqN67CjV1Rly5LI1bLHcO4d84 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo=E2=80=99, Thanks for explaining! =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, January 24th, 2022 at 9:18 AM, Ludovic Court=C3=A8s wrote: > > Grafting is a pretty basic process: in this case it replaces occurrences > of /gnu/store/=E2=80=A6-expat-2.4.1 with /gnu/store/=E2=80=A6-expat-2.4.3= , nothing more. > It cannot guess that libexpat.so.1.8.1 was renamed to libexpat.so.1.8.3 > or anything like that. > > Is it a problem? Normally no, because users of shared libraries don= =E2=80=99t > refer to libraries by their fully-qualified name: > > --8<---------------cut here---------------start------------->8--- > $ objdump -x $(guix build dbus-glib)/bin/dbus-binding-tool|grep NEED.*exp= at > NEEDED libexpat.so.1 > $ objdump -x $(guix build dbus-glib)/bin/dbus-binding-tool|grep RUNPATH > RUNPATH /gnu/store/wwmxxlmlhwljn39z0gsj6iai3zk67a2g-dbus-glib-0.110/lib:/= gnu/store/5s6iz5f777rh23q4kv8gvqrsyy61cbjh-dbus-1.12.20/lib:/gnu/store/s0w7= szfsajdy6cnrz2w7z4h5spyl4aaj-expat-2.4.1/lib:/gnu/store/2fk1gz2s7ppdicynscr= a9b19byrrr866-glibc-2.33/lib:/gnu/store/90lbavffg0csrf208nw0ayj1bz5knl47-gc= c-10.3.0-lib/lib:/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/li= b:/gnu/store/90lbavffg0csrf208nw0ayj1bz5knl47-gcc-10.3.0-lib/lib/gcc/x86_64= -unknown-linux-gnu/10.3.0/../../.. > --8<---------------cut here---------------end--------------->8--- > > Likewise, =E2=80=98etc/ld.so.cache=E2=80=99 contains a reference to = =E2=80=98libexpat.so.1=E2=80=99, not > to =E2=80=98libexpat.so.1.8.1=E2=80=99. > (Your example output was not of a grafted libexpat in the RUNPATH, but poin= t taken; I see the newer expat version on my (grafted) dbus-glib). > Does that make sense? Or am I overlooking something? > Yes, that makes sense, thank you for clarifying. So this is the currently e= xpected behavior. Ideally grafting would be smarter to maybe avoid this (mi= ssing changes in e.g. version number)? But I would guess this is not someth= ing that would be expected to cause a problem for the vast majority of case= s, as you explain, and adds complexity to the process. I'm glad to hear it all works! But... Perhaps I was too hasty in noting this "problem" which like I said was not = the error I originally encountered. I was using a package that constructs b= oth the 64- and 32-bit libraries to put in a container (say, a /lib32 and /= lib64 or something similar to an FHS environment). A collision was happenin= g between a file and directory, one being a good symlink and the other brok= en, rather than a "real" mismatch in file vs directory. Anyway, going back = to that what I see is that one link is broken for the above reasons, but th= e good one is good because it is to the *ungrafted* library store path. I d= on't know now if these 2 things are connected other than one led me to the = other, but I turn now to what demonstrates my original problem. I don't know why this happens or if it is something in this building proces= s that is not correct, but I did come up with a minimal example (attached).= The code is a bit odd in its stripped down form, though hopefully is clear= in what way this would be used to do something useful (again, like an FHS = environment or other container). Apologies for the old style and lack of ge= xps which I'm finally getting used to. The example package just tries to ma= ke a dummy package that has, for illustration, a "/lib64" and "/lib32" whic= h link to the respective union-build inputs (of a single library for simpli= city). I don't think the actual package being made matters so much, or how = it is constructed, but that two inputs are union-builds of the same library= (x86_64 and i686) which should have a graft of expat. Just my guess though= . Doing: ls -la $(guix build -f graft-test.scm)/lib64/lib/libexpat* lrwxrwxrwx 1 root root 71 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3jk= ji6i978-test-pkg-0.0/lib64/lib/libexpat.la -> /gnu/store/2q8wwhd3prib0swky6= 8rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.la* lrwxrwxrwx 1 root root 71 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3jk= ji6i978-test-pkg-0.0/lib64/lib/libexpat.so -> /gnu/store/2q8wwhd3prib0swky6= 8rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so* lrwxrwxrwx 1 root root 73 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3jk= ji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1 -> /gnu/store/2q8wwhd3prib0swk= y68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1* lrwxrwxrwx 1 root root 77 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3jk= ji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1.8.1 -> /gnu/store/2q8wwhd3prib= 0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1.8.1 is what we saw already: libexpat is the newer (replacement, 2.4.3) version,= with the full version symlink broken since the version number is wrong. Li= kewise in other pieces that have the version number, like share/doc. Okay, = that's expected. But now, in the i686-linux union-build input: ls -la $(guix build -f graft-test.scm)/lib32/lib/libexpat* lrwxrwxrwx 1 root root 71 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3jk= ji6i978-test-pkg-0.0/lib32/lib/libexpat.la -> /gnu/store/b0jns3vzhhpna7lim8= bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.la* lrwxrwxrwx 1 root root 71 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3jk= ji6i978-test-pkg-0.0/lib32/lib/libexpat.so -> /gnu/store/b0jns3vzhhpna7lim8= bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so* lrwxrwxrwx 1 root root 73 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3jk= ji6i978-test-pkg-0.0/lib32/lib/libexpat.so.1 -> /gnu/store/b0jns3vzhhpna7li= m8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so.1* lrwxrwxrwx 1 root root 77 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3jk= ji6i978-test-pkg-0.0/lib32/lib/libexpat.so.1.8.1 -> /gnu/store/b0jns3vzhhpn= a7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so.1.8.1* all the links are good and to the original (version 2.4.1) expat. In other = words, the constructed union64 and union32 inputs (in the sample code) do n= ot both get grafted, even though doing just the fhs-union command on it's o= wn (not building both for another package) does graft for either architectu= re. At least that seems like the most obvious difference between the earlie= r example and this new one. Why? Does the grafting just happen "once" somehow and misses the "same" inp= ut again (but built for different system)? Is this expected or just a weird= /wrong way to do this kind of build which is causing this? I'm not sure if = this is just with union-build or if it would happen just with inputs of the= same library but different architectures. I didn't know how to do that qui= ckly off hand, so I haven't tried it yet. Thanks for taking the time to look and explain, much appreciated! John --b1_hzGkhNMlchRq0mtQZRmqN67CjV1Rly5LI1bLHcO4d84 Content-Type: text/x-scheme; name=graft-test.scm Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=graft-test.scm Ozs7IEdOVSBHdWl4IC0tLSBGdW5jdGlvbmFsIHBhY2thZ2UgbWFuYWdlbWVudCBmb3IgR05VCjs7 OyBDb3B5cmlnaHQgwqkgMjAyMCBwa2lsbC05Cjs7OyBDb3B5cmlnaHQgwqkgMjAyMCwgMjAyMSBp c29uIDxpc29uQGFpcm1haWwuY2M+Cjs7OyBDb3B5cmlnaHQgwqkgMjAyMSBwaW5lYXBwbGVzCjs7 OyBDb3B5cmlnaHQgwqkgMjAyMSBKZWFuLUJhcHRpc3RlIFZvbGF0aWVyIDxqYnZAcG0ubWU+Cjs7 OyBDb3B5cmlnaHQgwqkgMjAyMSBLb3pvIDxrb3pvZGV2QHJ1bmJveC5jb20+Cjs7OyBDb3B5cmln aHQgwqkgMjAyMSBKb2huIEtlaGF5aWFzIDxqb2huLmtlaGF5aWFzQHByb3Rvbm1haWwuY29tPgo7 OzsKOzs7IFRoaXMgZmlsZSBpcyBub3QgcGFydCBvZiBHTlUgR3VpeC4KOzs7Cjs7OyBHTlUgR3Vp eCBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5 IGl0Cjs7OyB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl IGFzIHB1Ymxpc2hlZCBieQo7OzsgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVy IHZlcnNpb24gMyBvZiB0aGUgTGljZW5zZSwgb3IgKGF0Cjs7OyB5b3VyIG9wdGlvbikgYW55IGxh dGVyIHZlcnNpb24uCjs7Owo7OzsgR05VIEd1aXggaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUg dGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0Cjs7OyBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0 aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCjs7OyBNRVJDSEFOVEFCSUxJVFkgb3Ig RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCjs7OyBHTlUgR2VuZXJh bCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgo7OzsKOzs7IFlvdSBzaG91bGQgaGF2 ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCjs7OyBh bG9uZyB3aXRoIEdOVSBHdWl4LiAgSWYgbm90LCBzZWUgPGh0dHA6Ly93d3cuZ251Lm9yZy9saWNl bnNlcy8+LgoKKHVzZS1tb2R1bGVzCiAoZ3VpeCBidWlsZC1zeXN0ZW0gdHJpdmlhbCkKIChndWl4 IHBhY2thZ2VzKQogKGdudSBwYWNrYWdlcyBmb250dXRpbHMpCiAoZ251IHBhY2thZ2VzIGFwcikp CgooZGVmaW5lKiAoZmhzLXVuaW9uIGlucHV0cyAjOmtleSAobmFtZSAiZmhzLXVuaW9uIikgKHZl cnNpb24gIjAuMCIpIChzeXN0ZW0gIng4Nl82NC1saW51eCIpKQogICJDcmVhdGUgYSBwYWNrYWdl IGhvdXNpbmcgdGhlIHVuaW9uIG9mIGlucHV0cy4iCiAgKHBhY2thZ2UKICAgIChuYW1lIG5hbWUp CiAgICAodmVyc2lvbiB2ZXJzaW9uKQogICAgKHNvdXJjZSAjZikKICAgIChpbnB1dHMgaW5wdXRz KQogICAgKGJ1aWxkLXN5c3RlbSB0cml2aWFsLWJ1aWxkLXN5c3RlbSkKICAgIChhcmd1bWVudHMK ICAgICBgKCM6c3lzdGVtICxzeXN0ZW0KICAgICAgICM6bW9kdWxlcyAoKGd1aXggYnVpbGQgdW5p b24pKQogICAgICAgIzpidWlsZGVyCiAgICAgICAoYmVnaW4KICAgICAgICAgKHVzZS1tb2R1bGVz IChpY2UtOSBtYXRjaCkKICAgICAgICAgICAgICAgICAgICAgIChndWl4IGJ1aWxkIHVuaW9uKSkK ICAgICAgICAgKG1hdGNoICVidWlsZC1pbnB1dHMKICAgICAgICAgICAoKChfIC4gZGlyZWN0b3Jp ZXMpIC4uLikKICAgICAgICAgICAgKHVuaW9uLWJ1aWxkIChhc3NvYy1yZWYgJW91dHB1dHMgIm91 dCIpCiAgICAgICAgICAgICAgICAgICAgICAgICBkaXJlY3RvcmllcykKICAgICAgICAgICAgKGZv cm1hdCAjdCAiXG4gZGlyZWN0b3JpZXM6IH5hXG4iIGRpcmVjdG9yaWVzKSkpKSkpCiAgICAoaG9t ZS1wYWdlICNmKQogICAgKHN5bm9wc2lzICJMaWJyYXJpZXMgdXNlZCBmb3IgRkhTIikKICAgIChk ZXNjcmlwdGlvbiAiTGlicmFyaWVzIG5lZWRlZCB0byBidWlsZCBhIGd1aXggY29udGFpbmVyIEZI Uy4iKQogICAgKGxpY2Vuc2UgI2YpKSkKCihkZWZpbmUgZm9udGNvbmZpZy1maXhlZAogIChwYWNr YWdlCiAgICAoaW5oZXJpdCBmb250Y29uZmlnKQogICAgKHByb3BhZ2F0ZWQtaW5wdXRzCiAgICAg KG1vZGlmeS1pbnB1dHMgKHBhY2thZ2UtcHJvcGFnYXRlZC1pbnB1dHMgZm9udGNvbmZpZykKICAg ICAgIChyZXBsYWNlICJleHBhdCIgKEBAIChnbnUgcGFja2FnZXMgeG1sKSBleHBhdC9maXhlZCkp KSkpKQoKKGRlZmluZSAoY29udGFpbmVyLXBhY2thZ2UgcGtnLWxpc3QpCiAgKGxldCogKCh1bmlv bjY0IChmaHMtdW5pb24gcGtnLWxpc3QgIzpuYW1lICJmaHMtdW5pb24tNjQiKSkKICAgICAgICAg KHVuaW9uMzIgKGZocy11bmlvbiBwa2ctbGlzdCAjOm5hbWUgImZocy11bmlvbi0zMiIgIzpzeXN0 ZW0gImk2ODYtbGludXgiKSkpCiAgICAocGFja2FnZQogICAgICAobmFtZSAidGVzdC1wa2ciKQog ICAgICAodmVyc2lvbiAiMC4wIikKICAgICAgKHNvdXJjZSAjZikKICAgICAgKGlucHV0cyBgKCgi ZmhzLXVuaW9uLTY0IiAsdW5pb242NCkKICAgICAgICAgICAgICAgICgiZmhzLXVuaW9uLTMyIiAs dW5pb24zMikpKQogICAgICAoYnVpbGQtc3lzdGVtIHRyaXZpYWwtYnVpbGQtc3lzdGVtKQogICAg ICAoYXJndW1lbnRzCiAgICAgICBgKCM6bW9kdWxlcyAoKGd1aXggYnVpbGQgdXRpbHMpKQogICAg ICAgICAjOmJ1aWxkZXIKICAgICAgICAgKGJlZ2luCiAgICAgICAgICAgKHVzZS1tb2R1bGVzIChn dWl4IGJ1aWxkIHV0aWxzKSkKICAgICAgICAgICAobGV0KiAoKG91dCAoYXNzb2MtcmVmICVvdXRw dXRzICJvdXQiKSkKICAgICAgICAgICAgICAgICAgKGxpYjY0LXRhcmdldCAoYXNzb2MtcmVmICVi dWlsZC1pbnB1dHMgImZocy11bmlvbi02NCIpKQogICAgICAgICAgICAgICAgICAobGliNjQtZGVz dCAoc3RyaW5nLWFwcGVuZCBvdXQgIi9saWI2NCIpKQogICAgICAgICAgICAgICAgICAobGliMzIt dGFyZ2V0IChhc3NvYy1yZWYgJWJ1aWxkLWlucHV0cyAiZmhzLXVuaW9uLTMyIikpCiAgICAgICAg ICAgICAgICAgIChsaWIzMi1kZXN0IChzdHJpbmctYXBwZW5kIG91dCAiL2xpYjMyIikpKQogICAg ICAgICAgICAgKGZvcm1hdCAjdCAiXG51bmlvbjY0OiB+YVxudW5pb24zMjogfmFcbiIgbGliNjQt dGFyZ2V0IGxpYjMyLXRhcmdldCkKICAgICAgICAgICAgIChta2Rpci1wIChzdHJpbmctYXBwZW5k IG91dCAiL2JpbiIpKSA7IGR1bW15IGRpciBuZWVkZWQgdG8gYnVpbGQKICAgICAgICAgICAgIChz eW1saW5rIGxpYjY0LXRhcmdldCBsaWI2NC1kZXN0KQogICAgICAgICAgICAgKHN5bWxpbmsgbGli MzItdGFyZ2V0IGxpYjMyLWRlc3QpKSkpKQogICAgICAoaG9tZS1wYWdlICNmKQogICAgICAoc3lu b3BzaXMgI2YpCiAgICAgIChkZXNjcmlwdGlvbiAjZikKICAgICAgKGxpY2Vuc2UgI2YpKSkpCgo7 KGZocy11bmlvbiAobGlzdCBmb250Y29uZmlnLWZpeGVkKSkKOyhmaHMtdW5pb24gKGxpc3QgZm9u dGNvbmZpZykgIzpzeXN0ZW0gImk2ODYtbGludXgiKQo7KGZocy11bmlvbiAobGlzdCBmb250Y29u ZmlnKSkKOyhmaHMtdW5pb24gKGxpc3QgYXByLXV0aWwpKQoKKGNvbnRhaW5lci1wYWNrYWdlIGAo KCJhcHItdXRpbCIgLGFwci11dGlsKSkpCg== --b1_hzGkhNMlchRq0mtQZRmqN67CjV1Rly5LI1bLHcO4d84--