From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id aNiGJFLuV2b85AAAe85BDQ:P1 (envelope-from ) for ; Thu, 30 May 2024 05:11:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id aNiGJFLuV2b85AAAe85BDQ (envelope-from ) for ; Thu, 30 May 2024 05:11:14 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=retrospec.tv header.s=fm3 header.b=GsM1e+kO; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b="X CmJ9Iw"; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1717038674; 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:dkim-signature; bh=ruUCMejktWNNP5a45VTHhU2tqSEo6HqKUNSF9nw6JLU=; b=SeWlxUoNulbWN91tGixaG71sH86SFc5gs6UpoVXpyLt5G1uVkHLzaDecaLLJAwywooCnJc 1pjmYKexv5mj5xwJhnHqflmU2ru5hIxKBnXXSM/p0WFXUzaSab24QwBBJM0Wr//4aTHxjt hURevqetO11VY7qDZ9IcH0BGJlBwO0J/MGnmkmqA7jRnvS19wGQPO72UnKSLrHs3Id96da dwNzenK1NfEmbgwDM5AXGlIKsKORs77nt698e0e4MqRPadMzVc9fiyyyFHOzIc6GRzM0jD WSt11NKyI84rnN+EPtL3LkWgwXLo1tyGo9iL5VdiBr+nUkM4ESpb55DSvZCM6g== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1717038674; a=rsa-sha256; cv=none; b=j9WG+URtiLY1/xmncpm6+ei6YlcY5B5sc39NcRgscwVV/C33g9IxobCtTw6bCtcBiapAZE xgWBUcZWwhxZUmLjJizfjqmT+m4zcw1GWQzQFRxKMN3/6iva8zlPr7/OGsJQirQof46QgV sZVNmngpRJzNXui9u9dlezPhH9GR3OGFIV+XxuvmdMX3CimAl+M36wPa0WmsfEO2eQCYU+ ik1rSCKAn1t1JvHADPBmyAXtnKj9R3GgsYeaUO7G3S3ehbCLjhkmWYm1+TNs0hnN9pmhJ7 0ZtA533S87vXu+SUAogd7zTOTf2+8ZY1IrhWsNCGjtnuXVnWV0WoTH3IeocozQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=retrospec.tv header.s=fm3 header.b=GsM1e+kO; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b="X CmJ9Iw"; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" 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 551A77996C for ; Thu, 30 May 2024 05:11:14 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCWBp-00049K-NY; Wed, 29 May 2024 23:10:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sCWBn-00047Q-Ol for guix-patches@gnu.org; Wed, 29 May 2024 23:10:51 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sCWBn-0004V6-FJ for guix-patches@gnu.org; Wed, 29 May 2024 23:10:51 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sCWBx-0003cK-Lm for guix-patches@gnu.org; Wed, 29 May 2024 23:11:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#71121] [PATCH 2/3] gnu: librewolf: Rebuild source tarball Resent-From: Ian Eure Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 30 May 2024 03:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71121 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Maxim Cournoyer Cc: 71121@debbugs.gnu.org Received: via spool by 71121-submit@debbugs.gnu.org id=B71121.171703864313869 (code B ref 71121); Thu, 30 May 2024 03:11:01 +0000 Received: (at 71121) by debbugs.gnu.org; 30 May 2024 03:10:43 +0000 Received: from localhost ([127.0.0.1]:41456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCWBe-0003bd-Ad for submit@debbugs.gnu.org; Wed, 29 May 2024 23:10:42 -0400 Received: from wfhigh7-smtp.messagingengine.com ([64.147.123.158]:58371) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sCWBb-0003bO-AV for 71121@debbugs.gnu.org; Wed, 29 May 2024 23:10:40 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.west.internal (Postfix) with ESMTP id 02E72180014B; Wed, 29 May 2024 23:10:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 29 May 2024 23:10:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retrospec.tv; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1717038622; x=1717125022; bh=ruUCMejktWNNP5a45VTHhU2tqSEo6HqKUNSF9nw6JLU=; b= GsM1e+kO8xgObC+K0KdaNhhwf/jTTTmaLfb2ho0Qjh2VVKrjZ21veCwmSX5+gU9B t26l/b6iLpOmK4LtL4kAWzUprfOPXZptl5DaYH/bo8faLWfS1gq4GMFpvh+JJ8lb TZL6GVRdeOiwbrR0/klijFUEV9/o1WPXhanounTZpcIc/mEzTHaEgDHL2NO7LZjj ddvT88GAJIFdcvTcKjjrdIxtRaRLpNTkDgyJBFymaBprN7kcuLeNU2b2Ilhzzz28 EDByX2w4rjDSPEIpidMdYmTmpKL1uQEdqyxTpgs8vaH77NnyQPe2y6V2p4dl0hKG BiTkH+PzBjEMmAUSvEZR0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1717038622; x= 1717125022; bh=ruUCMejktWNNP5a45VTHhU2tqSEo6HqKUNSF9nw6JLU=; b=X CmJ9IwEpowIWJzY6Xim56GE1B6udo1P/M32yLYjcMIxVvENAUprLawtyAQEmOQTR M9l01I2cz1UkmjjYCrSzKvSq+mi+pbeRq0X562nmMPtz8Lyx/E3/qUJ0PjnfzZ39 o1gSwYFpbv+rWVGYFJIX2LxSBSMy7L6wY3OfsQMPgLH3Ryhrg+d5U0Lb+Ri0K2iX sMKC1G7ZnI7DQttUYu9LS6WJeW4GBYG+5JmMV9EtjoyTOeC1DuqD5O3XRpRYgRjJ tOtg0vRtrROzBA1Q7JVEBx7HMlhAq0Bcp44hDMWC6xVQkOYQa8GmNUGJFPBfakaz UnNReta+7vKtNDGJnIYyg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvdekfedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfhgfhffvvefuffgjkfggtgfgsehtqhertddtreejnecuhfhrohhmpefkrghn ucfguhhrvgcuoehirghnsehrvghtrhhoshhpvggtrdhtvheqnecuggftrfgrthhtvghrnh epueeltdeuvedvtdekffefvdeikeeuvdetudevgeeukeeufefgkeethfeuveelhffhnecu ffhomhgrihhnpegtohguvggsvghrghdrohhrghdpghhnuhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehirghnsehrvghtrhhoshhp vggtrdhtvh X-ME-Proxy: Feedback-ID: id9014242:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 29 May 2024 23:10:21 -0400 (EDT) References: <20240522145956.31218-1-ian@retrospec.tv> <20240522145956.31218-2-ian@retrospec.tv> <87jzjcf5nk.fsf@gmail.com> User-agent: mu4e 1.8.13; emacs 28.2 From: Ian Eure Date: Wed, 29 May 2024 18:48:11 -0700 In-reply-to: <87jzjcf5nk.fsf@gmail.com> Message-ID: <87a5k8uh9f.fsf@meson> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -1.95 X-Spam-Score: -1.95 X-Migadu-Queue-Id: 551A77996C X-Migadu-Scanner: mx11.migadu.com X-TUID: ESRexfwZK10X Hi Maxim, Maxim Cournoyer writes: > Hi Ian, > > Ian Eure writes: > >> * gnu/packages/librewolf.scm (librewolf): This patch removes an=20 >> intermediate >> step in the build chain. The upstream source tarball is=20 >> created with an >> automated build process, where Firefox sources are fetched,=20 >> patched, and >> repacked. Rather than download the output of that process, as=20 >> the package has >> been, it=E2=80=99s now replicated within the build process, similar to=20 >> how IceCat >> works. > > I think I'd rather keep using a human-prepared and vetted=20 > tarball, to > avoid anything going stale in our local recipe of how it's meant=20 > to be > prepared. > The upstream tarball is built by scripts run under a CI system=20 which triggers when changes are pushed[1], and aren=E2=80=99t=20 human-prepared or vetted in the same way that many release=20 tarballs have tradionally been. This patchset uses the same=20 script as upstream, with modifications to make it reproduceable,=20 as the upstream process isn=E2=80=99t. As noted in the commit messages, IceCat also builds this way[2],=20 including patching the upstream build script[3][4], so this seems=20 like a reasonable & accepted way to build. Though perhaps there=E2=80=99s= =20 dissatisfaction with the IceCat build which I wasn=E2=80=99t aware of,=20 being a fairly new contributor. > It's also simpler and less maintenance, and arguably shields > the users better against non-free source code (although I don't=20 > think > there's anything non-free in the Firefox tree, so that point is=20 > more > moot than say, for linux) to use a tarball. > > What do you or others think? > It=E2=80=99s definitely simpler to use the upstream tarball in most cases,= =20 which is why I went that direction when I initially packaged=20 LibreWolf. But, since IceCat builds this way, and the xz backdoor=20 was discovered hiding in the non-reproduceable build process, I=E2=80=99ve= =20 been intending to update the package to control the full build,=20 rather than trusting an unreproducable external process. I=20 understand that if the build scripts are backdoored, it doesn=E2=80=99t=20 matter whether upstream runs them or Guix does, but I believe that=20 aligning with IceCat and having a reproduceable build directly=20 from the upstream source repo are worthwhile. In the specific case of the 126.0-1 release, owning the whole=20 build process made things easier. Upstream backported a very=20 large Firefox change[5] which updates a bundled dependency to a=20 new version; that dependency doesn=E2=80=99t work with Rust 1.75, which is= =20 what=E2=80=99s in Guix. With the Guix build process controlling what=20 patches get applied, I was able to solve the problem by removing=20 one line from the manifest of patches to apply to the Firefox=20 source. If the package builds from the 126.0-1 tarball, it=E2=80=99ll=20 need to ship a 22,000-line patch(!) to back out that change. That=20 may still be necessary, depending on the timing of the rust-team=20 branch merging and the next Firefox release, but at least for now,=20 things are simpler. Ideally, this wolud be solved by unbundling=20 that (and the other) vendored Rust libraries (and that=E2=80=99s something= =20 I intend to look into), but I didn=E2=80=99t want to block security fixes=20 on work with unknown-but-probably-large scope -- there will almost=20 definitely be Rust libraries currently not packaged in Guix which=20 need to be addressed. As far as maintenance burden or things getting stale, the risk is=20 that upstream alters their scripts, which requires updates to the=20 Guix patches for them. This doesn=E2=80=99t seem like a major drawback to= =20 me, and I=E2=80=99m the one doing the maintenance. :) Overall, I think=20 it=E2=80=99s a reasonable tradeoff for the reproducability we gain. If=20 this approach to building LibreWolf in this patchset is acepted,=20 I=E2=80=99d like to work with upstream to make their build process more=20 flexible, ideally running it unmodified in the Guix build, which=20 would eliminate the risk. Lastly: I noticed that I neglected to update %librewolf-build-id=20 when I sent this patchset in. If my arguments are compelling=20 enough for you, I think it=E2=80=99d make sense to update that when the=20 changes are pushed (it=E2=80=99s a one-line change & the command to print=20 an ID are in the comment above the variable). But, if you=E2=80=99d like=20 a v2 patchset, either just to update that, or to back out the=20 build process change and replace it with a 22kloc patch, I=E2=80=99d be=20 happy to handle it instead. Thank you very much for your thoughts and the time you took to=20 respond. =E2=80=94 Ian [1]: https://codeberg.org/librewolf/source/actions/runs/168/jobs/0 [2]:=20 https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnuzilla.scm?i= d=3D898b5f30f3d485d48275c920da172863da9524c6#n530 [3]:=20 https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnuzilla.scm?i= d=3D898b5f30f3d485d48275c920da172863da9524c6#n571 [4]:=20 https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/icecat= -makeicecat.patch [5]:=20 https://codeberg.org/librewolf/source/commit/d292bdd2213a22e5b364339dfee68a= 27670f1b72