From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 10 08:46:41 2020 Received: (at 43249) by debbugs.gnu.org; 10 Sep 2020 12:46:41 +0000 Received: from localhost ([127.0.0.1]:37580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kGLyK-000569-QL for submit@debbugs.gnu.org; Thu, 10 Sep 2020 08:46:41 -0400 Received: from mout-p-201.mailbox.org ([80.241.56.171]:11366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kGLyH-0004zN-T9 for 43249@debbugs.gnu.org; Thu, 10 Sep 2020 08:46:38 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4BnJY34RW7zQlWQ; Thu, 10 Sep 2020 14:46:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brendan.scot; s=MBO0001; t=1599741989; h=from:from: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: in-reply-to:in-reply-to:references:references; bh=dTOO0DxLjahv3UQeVyui34QluZw3BZ1cBD0qHUxDzB0=; b=oxw/SfXe7Dfv5Soh0l8QyXsWWUh/JqQwvnjJf/Cb7NGwJZ1mTx/WiR9U3zUSBBg1tEAI+y yfKXca+BHqpIuq4zqqVDGzbVfYsGWC8USGicSi7R7KcT5Esc+f4fqpJ+nCEnSIwy722T6s 0dwcR755rxxqyZFJrPkfFrJLf+eVBh/lzboGqjDgSUIhbFOkrpN3uOreVx+bWMUJbdIwab iWfNjk3MA7x/JK2pTm5PD/p3ih/9bSUl1dsN/9tiNbBJ5Gl0OB0t+VQ+XAYcL9Ovb2VQ3I /OBfkcpyPsgJZCmOqZOiuk6oPvDHGMymiNSznLyTgJmBkGzfw1pYLpX/Toc2jg== Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id Uup9A_m1h0Ms; Thu, 10 Sep 2020 14:46:28 +0200 (CEST) Subject: Re: [bug#43249] To: Ricardo Wurmus References: <87d02wca8d.fsf@elephly.net> From: Brendan Tildesley Message-ID: <330470a6-e6d2-e679-32ac-a308d89a5e92@brendan.scot> Date: Thu, 10 Sep 2020 22:46:33 +1000 MIME-Version: 1.0 In-Reply-To: <87d02wca8d.fsf@elephly.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-MBO-SPAM-Probability: X-Rspamd-Score: -1.71 / 15.00 / 15.00 X-Rspamd-Queue-Id: 678DA17BB X-Rspamd-UID: 135af8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 43249 Cc: Prafulla Giri , 43249@debbugs.gnu.org, guix-patches@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.7 (-) On 9/9/20 5:57 am, Ricardo Wurmus wrote: > Prafulla Giri writes: > >> I wonder.... perhaps it'd be better altogether if the (wrap-program) >> procedure could be re-written to not make ..*.real.real programs...? That >> would save us a lot of code-duplication... > Looking at the definition of wrap-program in (guix build utils) there is > code that checks if the wrapper already exists; if it does it should > append the new environment variable definitions to the existing > wrapper. It looks like this doesn’t work reliably. > > If someone could figure out why that is we could fix this in the next > core-updates cycle. > When given "foo", wrap-program checks if ".foo-real" exists and thus concludes that "foo" is a wrapper and appends, however, despite the fact that the wrapper? procedure exists, it is not actually used at any time to check if ".foo-real" its self was passed to wrap-program. Therefore it happily wraps wrappers if it is given one. For example glib-or-gtk-build-system uses (find-files bindir ".*") to find files to pass to wrap-program. This ".*" regular expression matches hidden dotfiles. I copy-pasted everything to make a new build system and added an error for (wrapper? prog) and it exposed this. changingI guess then we should patch wrap-program to add (when (wrapper? prog)     (error (string-append prog " is a wrapper. Refusing to wrap."))) at the start. Then fix all uses of wrap-program so that they dont recieve -real files. In glib-or-gtk-build-system.scm, chanding bin-list to: (bin-list     (filter (lambda (file) (not (wrapper? file)))                                      (append (find-files bindir ".*")                                              (find-files libexecdir ".*")))) seems to fix it, at least in the case of gedit, a program that currently produces a nested wrapper. Ill play with it more tomorrow.