From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:58615) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1ht940-0000ox-0m for guix-patches@gnu.org; Thu, 01 Aug 2019 07:16:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ht93y-0003bG-Os for guix-patches@gnu.org; Thu, 01 Aug 2019 07:16:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:44748) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ht93y-0003bC-Jl for guix-patches@gnu.org; Thu, 01 Aug 2019 07:16:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ht93y-00060F-Cm for guix-patches@gnu.org; Thu, 01 Aug 2019 07:16:02 -0400 Subject: [bug#36841] [PATCH v3] build/cargo-build-system: Patch cargo checksums. Resent-Message-ID: Date: Thu, 1 Aug 2019 14:15:26 +0300 From: Efraim Flashner Message-ID: <20190801111526.GA6265@E2140> References: <20190729190422.6834-1-efraim@flashner.co.il> <20190730081757.GB21431@E2140> <20190730104658.GC21431@E2140> <6580AB76-AB78-4758-B71F-FE08687B9A33@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <6580AB76-AB78-4758-B71F-FE08687B9A33@gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ivan Petkov Cc: 36841@debbugs.gnu.org --T4sUOijqQbZv57TR Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2019 at 08:00:00PM -0700, Ivan Petkov wrote: > Hi Efraim, >=20 > > On Jul 30, 2019, at 3:46 AM, Efraim Flashner wr= ote: > >=20 > > This one I'm pretty happy with. The checksums are only generated twice > > when there's a Cargo.lock file present and I've factored out the > > function to generate all the checksums. When that's moved to (guix build > > cargo-utils) it can be used by the rust compilers and icecat. >=20 > Overall the patch makes sense to me! >=20 > However, I am curious what are some of the situations in which you=E2=80= =99re encountering > a Cargo.lock file? In a system like guix which maintains all dependencies= immutably > and consistently, the Cargo.lock file is virtually useless (in fact it *c= ould* be harmful > if an application is released with a Cargo.lock file pinning to a particu= lar vulnerable > dependency which needs to be updated, requiring patching of the Cargo.loc= k file). One is the package that I'm actually targeting, https://github.com/chfi/rus= t-qtlreaper/ , and three of the others are rust-regex and rust-compiler-builtins and rust-env-logger. All three of them I got from $(guix import crate foo). `guix import crate env-logger`, for example, returns this: https://static.crates.io/crates/env_logger/env_logger-0.6.2.crate >=20 > I=E2=80=99d be willing to go as far as suggest we unconditionally delete = any Cargo.lock file > in source tarballs and let cargo generate its own replacement using the v= endor > directory we have supplied. (Imports from crates.io a= lso never include a Cargo.lock > file, so this may only pertain if we=E2=80=99re performing a direct sourc= e import=E2=80=A6) This is basically what my 'update-cargo-lock phase does. Otherwise we end up packaging arbitrary versions of crates to satisfy whatever version they were using when they last updated their Cargo.lock. >=20 > =E2=80=94Ivan --=20 Efraim Flashner =D7=90=D7=A4=D7=A8=D7=99=D7=9D = =D7=A4=D7=9C=D7=A9=D7=A0=D7=A8 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --T4sUOijqQbZv57TR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAl1Cyb4ACgkQQarn3Mo9 g1GOGxAAhGpN3IS8G8UqUcAlFhgk/LmqeHGbjjFBQUclHDv30Mxo11civt+2uE6Q amtFP3WzyTo+xYVzk7vOG9SKH5JSbPmzJRMu2uxLEKf99Qp4woNd/moMkV7lW4Qy xZ01lJv7zNzDBVJITe835bnclscfuK16K8QDxxaruY+kbiCUMa35q28p9DogVatB rBn0Arg91lo+RycgQpUzGTHw17G3vWKmwRufElIlN/8nbkq5vkrRypLUdUhr86tH 76JiIQfX0KGr04r46mBJOELdmh9FdbcWuBVU5U5rRLKx3nUPKV7i+6E5CEsbZVkh 17UWVobRSeIQ1Lj3r5507go7VmcMVjFpuCvBscNWVuZL9r6n0W5TvXzZm/IbwNDE QLEuMAB8PV5gcIDKWOJn9EjhetToXMBpqVTiQVdCA+M06kIHBiho0Y2ZRU+C4kLj keXaQCmzC3sR2wAuXKRsH5mJNeJ+yxY5gq9QKwwQOdfTjgTgTAieidJ26+/G/fn/ C8KEJlBcWeQNn5Im/ktCp9gXbAXx1oIgjbZmAc6SfogghttDMFvivPWMHGIn1QC3 SssRs2v5rsr+gQ65/s4R/LPvu+dQUobMp4xkC56n9Vi6qu+V86P7xSzLSCrMmF17 +SglaEZ9KZDI8GZ2I8Lh8vMU1zZ4ldvcsSky7ushlAm+qQLr7Fs= =XjrY -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR--