From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 03 16:12:16 2021 Received: (at 33848) by debbugs.gnu.org; 3 Apr 2021 20:12:16 +0000 Received: from localhost ([127.0.0.1]:34475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lSmcx-00061B-Tl for submit@debbugs.gnu.org; Sat, 03 Apr 2021 16:12:16 -0400 Received: from world.peace.net ([64.112.178.59]:38716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lSmcw-00060w-9h for 33848@debbugs.gnu.org; Sat, 03 Apr 2021 16:12:15 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lSmcp-0000H2-Hq; Sat, 03 Apr 2021 16:12:08 -0400 From: Mark H Weaver To: Pierre Neidhardt , Guillaume Le Vaillant Subject: Re: bug#33848: Store references in SBCL-compiled code are "invisible" In-Reply-To: <87sg47vp16.fsf@ambrevar.xyz> References: <87r2e8jpfx.fsf@gnu.org> <87o9979gfn.fsf@gnu.org> <87tvizgghs.fsf@ambrevar.xyz> <87k1juaomo.fsf@gnu.org> <87muoqhk62.fsf@ambrevar.xyz> <87zhsq8wkj.fsf@gnu.org> <87d0pmhbgn.fsf@ambrevar.xyz> <87r2e28tkv.fsf@gnu.org> <874laygkiy.fsf@ambrevar.xyz> <87lfa5eymf.fsf@ambrevar.xyz> <87tuoscsk9.fsf@gnu.org> <87im57b8u7.fsf@ambrevar.xyz> <87czvebky2.fsf@netris.org> <87eefu30a4.fsf@gnu.org> <87im56l6es.fsf@yamatai> <87wntm8j18.fsf@ambrevar.xyz> <87a6qil4b1.fsf@yamatai> <87a6qiz5b3.fsf@ambrevar.xyz> <871rbtc3j5.fsf@netris.org> <87r1js9udv.fsf@netris.org> <87sg47vp16.fsf@ambrevar.xyz> Date: Sat, 03 Apr 2021 16:10:18 -0400 Message-ID: <875z139liy.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Pierre Neidhardt writes: > Wow, that was fast, thank you Mark! > > Any idea how I can test this, i.e. how I can force a graft? Just apply the patch to a git checkout of Guix, build it, and then use it to build anything you like, e.g. "./pre-inst-env guix build nyxt". Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: ambrevar.xyz (xyz)] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record X-Debbugs-Envelope-To: 33848 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , 33848@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) Pierre Neidhardt writes: > Wow, that was fast, thank you Mark! > > Any idea how I can test this, i.e. how I can force a graft? Just apply the patch to a git checkout of Guix, build it, and then use it to build anything you like, e.g. "./pre-inst-env guix build nyxt". With this patch applied, all graft derivations will be rebuilt, but *only* grafts. When it's ready (i.e. when it has better comments, docstrings, etc), this change is perfectly appropriate for 'master'. FYI, I've already applied this new grafting code to my private branch of Guix, switched to a system and user profile built using it, rebooted into the new system, and I'm typing this email on it. I've also checked that none of the processes running on my system include executables or shared libraries from ungrafted store items (after removing my ibus .cache files, see ). Mark