From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 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 dcvr.yhbt.net (Postfix) with ESMTPS id CEB0D1F44D for ; Thu, 25 Apr 2024 17:43:48 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s037o-00025P-Rb; Thu, 25 Apr 2024 13:43:12 -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 1s037m-00024x-4F for bug-gnulib@gnu.org; Thu, 25 Apr 2024 13:43:10 -0400 Received: from uggla.sjd.se ([2001:9b1:8633::107]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s037X-0006Zj-52; Thu, 25 Apr 2024 13:43:09 -0400 DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2303; h=Content-Type:MIME-Version:Message-ID:In-Reply-To :Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description; bh=zEg465pSQVIWez8kp8AFPvnE1Hu4HLi9UNmL1z0HDzo=; t=1714066973; x=1715276573; b=jmTWdfuT7yWerKKGDZ5+K1BbQXKA2JdWQVRlFi5Qh9kY265m7bD69nMV5gjBy3v3ssuecod2MMh EenhNVquQAA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2303; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zEg465pSQVIWez8kp8AFPvnE1Hu4HLi9UNmL1z0HDzo=; t=1714066973; x=1715276573; b=ZSAKrrpyrjZ6iVJo0s60Ho8TFeliIuRkGZplM4UUqXv35vcAej6c/hd0+K4juT5HM3CTv0ksSjY SKRtIKpWeVW/Rf9KY3SGk8jKLvngyiTZXSIGYUiG4F7Mz/MC+6CI8S4i8m+YWm2LuszarVp+My8VY xJGPXRE8vtQdb1Xqdu8zG2wLNUj+CE/esZvx4zhCrSHTeUEYywjeAU65XyzkEDppDuf1JgdK51Q61 K7FVu96SFimvXui8D2N489ZLrnS0UQF7S8TZlstkiWzdQSFU1N8AJ5ACvZo0jSjnlD1Vt36opQHW5 G4mQ7Gq4k19CwLhV6gyw5OH3UPxbZYf7rr5hZR3BqWUVwswmfAbptkGDQTIbcKgdRYCjn2MZW20Oi bAphaSOl6f8TBTntBAu4uVkXdFbHqvFeEcby2TEYkMDCQVdC2B4YNMAfoXHaagGSRatOjOT7+; Received: from [2001:9b1:41ac:ff00:823f:5dff:fe09:16ac] (port=45484 helo=kaka) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1s037R-000FWS-Vr; Thu, 25 Apr 2024 17:42:50 +0000 To: Paul Eggert Cc: Bruno Haible , Reuben Thomas , bug-gnulib , Paul Smith Subject: Re: GNULIB_REVISION References: <8734radfti.fsf@kaka.sjd.se> <860782103.rUtxlePDI0@nimes> <87msphbe8g.fsf@kaka.sjd.se> <4a1d5684-f671-40df-9bd9-cb12dbd49c06@cs.ucla.edu> OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt X-Hashcash: 1:23:240425:eggert@cs.ucla.edu::Shf4jLbtz8DO1sfL:2Pvj X-Hashcash: 1:23:240425:psmith@gnu.org::5PDf45S7SoEuogeS:DwBD X-Hashcash: 1:23:240425:rrt@sc3d.org::jIivao/l/UyYJBkA:WXe/ X-Hashcash: 1:23:240425:bug-gnulib@gnu.org::g3O3Rbt3yS4//QaP:0Bif4 X-Hashcash: 1:23:240425:bruno@clisp.org::l6an4uLknxu9JoJb:0pbg+ Date: Thu, 25 Apr 2024 19:43:04 +0200 In-Reply-To: <4a1d5684-f671-40df-9bd9-cb12dbd49c06@cs.ucla.edu> (Paul Eggert's message of "Thu, 25 Apr 2024 10:00:01 -0700") Message-ID: <87edatbaon.fsf@kaka.sjd.se> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: pass client-ip=2001:9b1:8633::107; envelope-from=simon@josefsson.org; helo=uggla.sjd.se X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Simon Josefsson From: Simon Josefsson via Gnulib discussion list Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Paul Eggert writes: > You raise several good points. A couple of quick reaction: > > On 2024-04-25 09:26, Simon Josefsson via Gnulib discussion list wrote: > >> - the gnulib git submodule is huge. Not rarely I get out of memory >> errors during 'git clone' in CI/CD jobs. > > First I've heard of this problem (other than with Git LFS, which > Gnulib doesn't use). What part of the clone operation fails? Is this=20 > server-side RAM, or client-side RAM, or something else? How much > memory does 'git clone' require now for Gnulib? > > Is there some way to cajole 'git clone' into using less memory, with a > '--depth 1' or similar options? Cloning shallowly would clone Gnulib a=20 > lot faster, if you're cloning from a remote repository. It only happens once in a while, for example: https://gitlab.com/gsasl/inetutils/-/jobs/6706396721 This is gitlab's own git submodule checkout system working, and it is using --depth 150 which shouldn't be too heavy, so it not even getting to ./bootstrap's git clone. Btw, using --depth 1 is incompatible with gnulib's git-version-gen: it will not find a suitable version number for the build. Even gitlab's default depth of 50 (or if it was 100, can't remember) is often not enough if you have >50 commits since the last release. This cause problems when building from 'git archive' tarballs. >> - we don't offer any way for people receiving tarballs to learn which >> gnulib git commit was used > > Isn't the real problem that we don't put (for example) gzip's own > commit ID into the coreutils tarball? If we did that, Gnulib's commit > ID would come for free, since it can be derived from gzip's commit ID. I suppose you meant s/coreutils/gzip/, otherwise I don't follow? Yes that is a good idea! The git commit of the project should be part of the announce-gen output. The git tag name could be mentioned too. Tags are not long-term stable since they can be moved later on, so I think the full git commit id should be mentioned too. Current SHA1 git commits aren't long-term stable either, since SHA1 is broken, but at least this approach is the best we can do right now and when we move to SHA256 git things will be better. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZiqWKBQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFovXeAQC+VQYeucBYWtCrq2GzoM5zTj+1FZAm /ziGeyIK7GmQ7QEAgB1n8hMM50CGOk6XE3sMgsxL/W8wsWxcpMBpv/mR2g4= =ycp6 -----END PGP SIGNATURE----- --=-=-=--