From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 SJTfB0oZ8GF2BAEAgWs5BA (envelope-from ) for ; Tue, 25 Jan 2022 16:37:46 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id GIFtOkkZ8GHoBgEAG6o9tA (envelope-from ) for ; Tue, 25 Jan 2022 16:37:45 +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 7AE0D43DBF for ; Tue, 25 Jan 2022 16:37:45 +0100 (CET) Received: from localhost ([::1]:58978 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCNtA-0004lv-Hs for larch@yhetil.org; Tue, 25 Jan 2022 10:37:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49954) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCMB4-0001fJ-6g for bug-guix@gnu.org; Tue, 25 Jan 2022 08:48:08 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:54566) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nCMB0-0001AB-6i for bug-guix@gnu.org; Tue, 25 Jan 2022 08:48:04 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nCMB0-0005nv-6i for bug-guix@gnu.org; Tue, 25 Jan 2022 08:48:02 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#53406: union-build incorrectly handles grafts Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Tue, 25 Jan 2022 13:48: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: John Kehayias Received: via spool by 53406-submit@debbugs.gnu.org id=B53406.164311847322265 (code B ref 53406); Tue, 25 Jan 2022 13:48:02 +0000 Received: (at 53406) by debbugs.gnu.org; 25 Jan 2022 13:47:53 +0000 Received: from localhost ([127.0.0.1]:47469 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCMAr-0005n2-8X for submit@debbugs.gnu.org; Tue, 25 Jan 2022 08:47:53 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]:56364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nCMAo-0005m6-Df for 53406@debbugs.gnu.org; Tue, 25 Jan 2022 08:47:51 -0500 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id E66BB1E8; Tue, 25 Jan 2022 14:47:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZnu94PIBy87; Tue, 25 Jan 2022 14:47:42 +0100 (CET) Received: from ribbon (91-160-117-201.subs.proxad.net [91.160.117.201]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 313D78B; Tue, 25 Jan 2022 14:47:42 +0100 (CET) From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <878rv5ushp.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 6 =?UTF-8?Q?Pluvi=C3=B4se?= an 230 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Tue, 25 Jan 2022 14:47:41 +0100 In-Reply-To: (John Kehayias's message of "Tue, 25 Jan 2022 03:22:44 +0000") Message-ID: <87bl00lyf6.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Rspamd-Server: hera X-Rspamd-Queue-Id: E66BB1E8 X-Spamd-Result: default: False [-0.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVRCPT(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] 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: , Cc: 53406@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-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=1643125065; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: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; bh=GpxR/OVP1DN2LQVFvi6mV1Sb9hkbVCDCQ97/FqW6zW8=; b=gAjUX1phqPwPcDwNPG2Naw3GVtIi431Ddqyw5kHdzfPx5MZOdNV7WGCDDYyJA2TpJcmgaE hTiGqtGBwps3dfBR4eOwJxoXig3LtDw4l985/oxeF0CToVMNvGx13r3T5dGiMQWVHXBEMB oxXE9Iot8C8znIQRmBru2WxlvOPIhXAZPR+BRhmuqvktMzdckphgJrfUDXoXH9XV0OE3A7 asULTXU9Nhu0qA6/LZwphkjFrDL9Bl252+P0QFGHXoGpi5mvGCb9NYdWksSgeDMvXTqfy6 rNCNRnxUg4a6IJBUwKgXQCR28kzR11Pk2PZDLFIBqqY0rm61yXWT/3/vA0UKoQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643125065; a=rsa-sha256; cv=none; b=IoWml0fi03ChL1sSAD+ihye4wKGCx6wEfR38ynFHvolH3hCnLZmIEw2lwLKAa0nMpwugHK FvS9p4WdxgaD5fYGPXlzdsEIU2FtggVHA2+/Jt6PV6fEP+h3sFYpt63/HfJXbgEQWvkmlV 4x2UARjKYEiZu5jNx0tBJFrXa7f9MW6zlI8F3jiPiSn+FXJqWBT7IkJ7GYrV/T0MLAEovN r00VvDfAsj5oO5a6uA1P7mXJPXcJSvu3nGHV7c7FM2Our4bqfa4mmooDCdD5ULCnb5fN7o sanqMVAuwwq8w/28g4YMjrsWSEdqA1qHNT5pgkFIlPh5T2bSsvK2QQOstKJytA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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: -3.63 Authentication-Results: aspmx1.migadu.com; dkim=none; 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: 7AE0D43DBF X-Spam-Score: -3.63 X-Migadu-Scanner: scn1.migadu.com X-TUID: BwjfLysH7pqm Hi John, John Kehayias skribis: > Yes, that makes sense, thank you for clarifying. So this is the currently= expected behavior. Ideally grafting would be smarter to maybe avoid this (= missing changes in e.g. version number)? But I would guess this is not some= thing that would be expected to cause a problem for the vast majority of ca= ses, as you explain, and adds complexity to the process. I don=E2=80=99t think it can be smarter; grafting is just text substitution= , it knows nothing about the files it=E2=80=99s fiddling with (with the exceptio= n of debugging sections in ELF files). > Perhaps I was too hasty in noting this "problem" which like I said was no= t the error I originally encountered. I was using a package that constructs= both 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 happen= ing between a file and directory, one being a good symlink and the other br= oken, rather than a "real" mismatch in file vs directory. Anyway, going bac= k to that what I see is that one link is broken for the above reasons, but = the good one is good because it is to the *ungrafted* library store path. I= don't know now if these 2 things are connected other than one led me to th= e 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 proc= ess 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 cle= ar in what way this would be used to do something useful (again, like an FH= S environment or other container). Apologies for the old style and lack of = gexps which I'm finally getting used to. The example package just tries to = make a dummy package that has, for illustration, a "/lib64" and "/lib32" wh= ich link to the respective union-build inputs (of a single library for simp= licity). I don't think the actual package being made matters so much, or ho= w it is constructed, but that two inputs are union-builds of the same libra= ry (x86_64 and i686) which should have a graft of expat. Just my guess thou= gh. > > Doing: > > ls -la $(guix build -f graft-test.scm)/lib64/lib/libexpat* > lrwxrwxrwx 1 root root 71 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3= jkji6i978-test-pkg-0.0/lib64/lib/libexpat.la -> /gnu/store/2q8wwhd3prib0swk= y68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.la* > lrwxrwxrwx 1 root root 71 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3= jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so -> /gnu/store/2q8wwhd3prib0swk= y68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so* > lrwxrwxrwx 1 root root 73 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3= jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1 -> /gnu/store/2q8wwhd3prib0s= wky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1* > lrwxrwxrwx 1 root root 77 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3= jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1.8.1 -> /gnu/store/2q8wwhd3pr= ib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1.8.1 > > is what we saw already: libexpat is the newer (replacement, 2.4.3) versio= n, with the full version symlink broken since the version number is wrong. = Likewise 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/qbh16hfdv8pnfw01k6izbs3= jkji6i978-test-pkg-0.0/lib32/lib/libexpat.la -> /gnu/store/b0jns3vzhhpna7li= m8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.la* > lrwxrwxrwx 1 root root 71 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3= jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so -> /gnu/store/b0jns3vzhhpna7li= m8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so* > lrwxrwxrwx 1 root root 73 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3= jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so.1 -> /gnu/store/b0jns3vzhhpna7= lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so.1* > lrwxrwxrwx 1 root root 77 Dec 31 1969 /gnu/store/qbh16hfdv8pnfw01k6izbs3= jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so.1.8.1 -> /gnu/store/b0jns3vzhh= pna7lim8bc3dr0payzx5yy-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 othe= r words, the constructed union64 and union32 inputs (in the sample code) do= not both get grafted, even though doing just the fhs-union command on it's= own (not building both for another package) does graft for either architec= ture. At least that seems like the most obvious difference between the earl= ier example and this new one. > > Why? Does the grafting just happen "once" somehow and misses the "same" i= nput again (but built for different system)? Is this expected or just a wei= rd/wrong way to do this kind of build which is causing this? I'm not sure i= f this is just with union-build or if it would happen just with inputs of t= he same library but different architectures. I didn't know how to do that q= uickly off hand, so I haven't tried it yet. Woow, it=E2=80=99s a sophisticated example. :-) I don=E2=80=99t actually have the Expat replacement we=E2=80=99re talking a= bout so I can=E2=80=99t easily test. At first sight I=E2=80=99d say it should work (both lib32 and lib64 should = refer to the Expat replacement), but it could be that something somewhere assumes all the packages are built for the system. That would need more investigation work in (guix packages) in (guix grafts). Thanks, Ludo=E2=80=99.