Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 74413) by debbugs.gnu.org; 13 Feb 2025 10:10:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 13 05:10:10 2025 Received: from localhost ([127.0.0.1]:40697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tiWAb-0002TY-Sh for submit <at> debbugs.gnu.org; Thu, 13 Feb 2025 05:10:10 -0500 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:61668) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1tiWAa-0002OS-EN for 74413 <at> debbugs.gnu.org; Thu, 13 Feb 2025 05:10:08 -0500 Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5dec817f453so1014405a12.2 for <74413 <at> debbugs.gnu.org>; Thu, 13 Feb 2025 02:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739441402; x=1740046202; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=TrsvU/QTWolU27m5KgmMsALSB86ZQ0d/wqhhBLbGIk4=; b=JXjV/kyumb8HflbEGGQeXCRXhi+iQ3M9bs5U579XzRZlD8Vwb88R67hH6qhx3FWzCI W6lz8jfy1NWFmf2lAIbhxSM7Amu7L+lVekiSUXjUYkXNH/UmRtKOG9qJsdO9HgPrFlMc M+N9Ndy3YfuPXhKKFT9l+efeBjdS80M7pG85deID1lYqBOgsTus7uJo4sRix67C3pwHN UhmktiwdHO7jTQyPxfXxgqw49OVjR9X79twEjSrfpZc3LN176XGNwPzdfzlA1JkhvPBI 8gKmqN/SrOkQLppEG7u5oqspix/fq/2otqpcKaduqvZBSKSIlh5WQ2Mbzl5Svor1/okt RF9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739441402; x=1740046202; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=TrsvU/QTWolU27m5KgmMsALSB86ZQ0d/wqhhBLbGIk4=; b=HIWrHx06pYt00cHL5iU1vKef1LGxDlcZNvOo0cwZ1lA9pw+toARKjbjnM1xqCzblb+ aF8GEjCDbpbKg6tu7eruSREnylL3u60dpqCn+VdpBlIu39wXTv5G6BS9rGGCg1jqfk4/ PyCHAFM8HXaSR9t9KxzKXKAnFV1nwXypVSuiYpiTOtToPVuuBujMK777U20rXHqE7str mwRwgFWkam/f5Fwil9PYbDbjEXi8xWWWizDaiBs3J321g11H1hVVKmqJETNrL2tj60Un YwoBs+Bg57LVJdvolPk9aGurAr7EaOWpoFE0EBSfBPOi57IzlienMIkGgM2Jd/GwS5H/ tJSA== X-Forwarded-Encrypted: i=1; AJvYcCW7IXI//m2Iw0oF/F21+1AQ1i79GoNFzNP0rYZiGHTCc73jmYIYOy9s/C71HC19gCo5UpOLtQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzvTiAmZSwEezrDq88HLN/OEootyP5Fqw+VV2u9UgIG5roAC8fK Ea+SmdSNpyahgDN8G+sAWLgsPUgbaAZ04DBVoT7Be1soyZm1Yq4P5fik7kt1giwazMnr85//jW2 YUG5BWf1BF8RIAZWsqqc9kVe77MAsiolRcJh63A== X-Gm-Gg: ASbGncvmyNqJIESvRFUzFaxF2iDjHxPEhfL5RS6vUVRL68SOABIcipsAxdBYRD1x9rX 1hBmHs/cOsMaGfi35LOgdIv1EYTn46jdQcnL/MWxyRoOKbypWen897IlGGBxCdHgAP7/hslT7Eo 0= X-Google-Smtp-Source: AGHT+IHDFuPgt6BHdV+ou0KJVK7yRvuhvJocpVtPCGkRj7GIlum1zdxRZQr7m9uFvUBa96gKzWWiiRt6nnL/5XDfuis= X-Received: by 2002:a05:6402:4316:b0:5cf:e9d6:cc8a with SMTP id 4fb4d7f45d1cf-5deade00a52mr5514179a12.20.1739441402242; Thu, 13 Feb 2025 02:10:02 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 13 Feb 2025 02:10:01 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <87mshmdn35.fsf@HIDDEN> References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@HIDDEN> <673c31c6.a70a0220.18f62b.10d8SMTPIN_ADDED_BROKEN@HIDDEN> <CADwFkmmpDpf5sE-qFOB5+wFKJ3DpqxdrbhLpT9g3qCXUe=7Eyg@HIDDEN> <87mshmdn35.fsf@HIDDEN> MIME-Version: 1.0 Date: Thu, 13 Feb 2025 02:10:01 -0800 X-Gm-Features: AWEUYZlTG3jsZMhqP5OMiwGDlkjVL2m5m2HPHzN0Uj-WUEqkD00Am5iK15d2_As Message-ID: <CADwFkmkYhgSyRiKGP7A=epWt2VyJYc5hVTYjdeWJHb0_Y8LAdg@HIDDEN> Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds To: =?UTF-8?B?QmrDtnJuIEJpZGFy?= <bjorn.bidar@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN> writes: > The Android builds obviously have the revision already integrated > as the logic that I'm trying to reuse here have been already > implemented for Android. > I don't know about the Guix build process but for Arch git isn't > into the change-root when building Emacs from the tarball that has been > generated before hand. > > The OBS can build packages for all kinds of Linux distributions such as > Flatpak, Debian, Fedora, SUSE, Ubuntu etc. > > So this change can help building test builds for all these distributions > in theory. Personally just building for SUSE. Could you please see if you can't work around this in the OBS build scripts themselves? I'd really rather not introduce yet another complication into our already extremely complex build process. Even understanding the use case here was a struggle, and having this in our build process means that we have to continue maintaining it. So for now, I believe this is a wontfix. Sorry, and thanks for understanding. Please let us know if all such efforts fail, however, and we might reconsider.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 74413) by debbugs.gnu.org; 26 Nov 2024 15:36:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 26 10:36:05 2024 Received: from localhost ([127.0.0.1]:50081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tFxbh-00009h-3P for submit <at> debbugs.gnu.org; Tue, 26 Nov 2024 10:36:05 -0500 Received: from thaodan.de ([185.216.177.71]:54770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <bjorn.bidar@HIDDEN>) id 1tFxbd-00009F-RS for 74413 <at> debbugs.gnu.org; Tue, 26 Nov 2024 10:36:04 -0500 Received: from NordStern (unknown [185.252.118.71]) by thaodan.de (Postfix) with ESMTPSA id 5E18BD00057; Tue, 26 Nov 2024 17:36:00 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1732635360; bh=ACnm+D0O9gr4NK+1s/xB/Kzl6npHxrRuBehCW6GuGYM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=g7/kJLcm2UJict3z807scTLQWtR7o3CmSYcQCH5ntOa+67u/v0Kkj/y9lM+uL740U 38TNZJo5e1yAQMeGwboO1Mk7xCiocArz8g+KrOvAGPrXlRnnwYJfaLYapWNOelhoFe 4/qWWFW2wLvG7DJ65GzTFstqn0s1D66WljBhS7pglYNsZLiyThpoUN/vu4obWFEPTG bqiLIHtporitBbCkgpUMMUqb6YnRfnUYls89E6mHMTuIb90/8S0qmnmBm1mpYAYTCo GrgTb56kHm4ggjjg3wwHYyNULQHyrth5Tgjtm9m7IQw7vgz650paYJGhNXNzev64SU UhnOcHh4qrBRlhm+7MFA79NiDGV16t0tR1XiFclaFtvtXsiw96O1kYj+xbGTf+WUlT cW9Xn+cyxIQeoN0qAmv37KX4aBS9Mmlpy3jQ2q6CfICZ7YaFY/Vqhl1H4l1hBKc4dC a2EjurnRp1qpg9jdHoaQn+5GpgfdSXMg4ccdB6DdohDPf4e6zi/6zeebROCob/6Gsj eBJ6cr2nGjRRYQw06F/1ee63lG3hTUsQVrNs3IGKvpMXX8xmCLqS4ktqB8eAu/Uczo PJubEBBh6tz96mERHVsBM0GMNrTChPO1i87WLM5AEWMc9s2BlUxTp4hhPi4wmXgBYF CLHWy+ZfkD1s05LIusHk2uE0= From: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN> Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds In-Reply-To: <CADwFkmmpDpf5sE-qFOB5+wFKJ3DpqxdrbhLpT9g3qCXUe=7Eyg@HIDDEN> (Stefan Kangas's message of "Mon, 25 Nov 2024 15:43:41 -0800") References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@HIDDEN> <673c31c6.a70a0220.18f62b.10d8SMTPIN_ADDED_BROKEN@HIDDEN> <CADwFkmmpDpf5sE-qFOB5+wFKJ3DpqxdrbhLpT9g3qCXUe=7Eyg@HIDDEN> Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA== Date: Tue, 26 Nov 2024 17:35:58 +0200 Message-ID: <87mshmdn35.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Kangas <stefankangas@HIDDEN> writes: > Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN> writes: > >>> I don't fully understand how you can have a situation where you can get >>> this information in the Makefile, but you can't also get it when dumping >>> using `emacs-repository-get-version` and `emacs-repository-get-branch` >>> (lisp/loadup.el:474). Could you please elaborate on this? >> >> I added the Makefile part so it would work outside of my environment if >> one builds Emacs and then distributes/install it without the sources or >> without them containing the VCS information while git is also installed >> in their build environment. > > I don't think I understand what you're saying here. Is it possible that > there are some typos above? I'm thinking of the part that contains the > tautology "without the sources or without them". I meant to say that if a user builds with Git installed and Emacs sources=20 checked out from git. Then packages Emacs but only puts the checkout sources without the VCS information into the source package/tarball. > There are also some words where the meaning is not entirely clear to me, > such as "distributes" and "installs". Distributed in this case meant to be the package build put into a repository and then installed using a package manager. > Maybe it will be clarified by the answers to my below questions. > >>> Do you mean that you have one containerized process with Git that clones >>> emacs.git into a directory, and then an entirely separate containerized >>> process, without Git, builds Emacs from that very same directory? Or >>> something along those lines? >> >> Yes more or less. >> I'm using an obs source service that generates a tarball from VCS's and >> then creates a tarball. [1] > > I took a look at the linked documentation, but it seems to be on a very > detailed level, and does not provide a good overview. So I don't think > I understood much from it. > > I'm not familiar with the Open Build System, so this is quite hard for > me to follow. Please be patient with me. > > In your description above, could you explain what is the difference > between the two steps "generates a tarball from VCS" and "creates a > tarball"? It should have be more detailed or used the proper word. The program that I use to generate the sources fetches the sources from a VCS such as git and then creates a cpio archive (for storing the sources more efficiently but that's beyond this topic). The cpio archive is then converted to a tar archive and compressed. > Do you mean to say that it: > 1) generates a tarball from emacs.git, excluding the .git directory > 2) copies that tarball to a completely different environment > 3) builds Emacs Essentially yes. The point of this is that the environment that builds the packages is disconnected from internet or other external factors for security reasons. The tarball is copied into the build environment while it prepares it so that a minimal linux vm or chroot can start to build software. > The part that I do not understand is in which step you run `make`, and > how. Is it run in the first step, the third, the first and the third, > or something else? Is it run automatically by OBS, or do you have to > specify it? I run make in in the 3 step right after the environment is setup up inside rpmbuild. Before make is called I parse the file that contains the reference hash and the file that contains the configuration for the program that generates the sources which contains the branch that the source where generated from into the file that Emacs then can read during the build process and after that when the package was installed. The only part that's special here is that I generate the version file from the information gathered while generating the source tarball as opposed to using git to gather those. > Basically, I still don't understand the answer to my below question: > >>> In this very particular scenario, isn't it enough to add this >>> additional step to your CI pipeline: >>> >>> ./src/emacs -Q --batch --eval '(princ (format "%s:%s" \ >>> emacs-repository-version emacs-repository-branch))' > version.info >> The obs source service already contains that information see the >> emacs.obsinfo file I mentioned earlier. > > Hmm. Would an alternative solution be to read the version information > from that file then, if it exists? > >>> In other words, is it really necessary for us to support this use case >>> in our Makefile? Do we expect that building Emacs in such CI pipelines >>> using non-released development version of Emacs will be very common? >> >> The Makefile target is there already for the Android builds all I did I >> added it to other platforms too. If the target would be shared then the >> hole process is reused. > > If we want this for other builds, then reusing what we do for the > Android build sounds prudent. It is clear that this is needed for > Android. What remains to clarify is why it is needed elsewhere. > >> I think it would become more common to build from VCS sources would be >> become more common where the information is useful. > > Building from VCS sources is already quite common. I'm asking something > more specific: will it be increasingly common to build using an > environment very similar to OBS? I think so. It's already quite common to build software in a much simpler CI such as Gitlab CI. Fedora has their own CI similar to OBS for ex= ample. > If it is not going to be very common, this should perhaps be fixed in > the OBS pipeline directly, instead of complicating our Makefile. But > I'm not yet clear on whether that is true. The makefile only has the rule add or moved for the version file. To me this just looks like refactoring so the logic that was added for Android can used on other platforms. >> To get more users to test earlier development builds to have faster >> general feedback and bug reports reports it is very useful to have >> non-released development builds. There are other instances outside my >> own usecase where this is frequent such as for example the AUR emacs-git= , guix >> emacs-next or the Android Fdroid builds. > > Are you saying that AUR emacs-git, guix emacs-next, and the Android > Fdroid builds also have no way to know which revision Emacs was built > from without your patch? The Android builds obviously have the revision already integrated as the logic that I'm trying to reuse here have been already implemented for Android. I don't know about the Guix build process but for Arch git isn't into the change-root when building Emacs from the tarball that has been generated before hand. The OBS can build packages for all kinds of Linux distributions such as Flatpak, Debian, Fedora, SUSE, Ubuntu etc. So this change can help building test builds for all these distributions in theory. Personally just building for SUSE. >>> BTW, what is the name of that CI system that you're using here? For >>> what purpose are you building Emacs: to test Elisp packages, to test >>> Emacs, or something else? Finally, why are you not using officially >>> tagged versions, either from us or from some distro, in this context? >> >> I'm build Emacs on the open build service. I'm building Emacs on the obs >> to provide development builds that can be used to test Emacs and submit >> bug reports. >> The package is build using the official RPM packaging just >> with the newer sources from git. >> >> The initial reason reason was that I noticed that even if you build from >> git directly without a CI/or something similar to the source service >> mentioned earlier that the functions to retrieve the repository >> information don't work since the source path either doesn't exist on any >> the machine that installs the final package or that it doesn't contain >> the VCS information anymore. >> The setup is very similar to the Android builds. > > Thanks. No problem.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Received: (at 74413) by debbugs.gnu.org; 25 Nov 2024 23:44:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 25 18:44:46 2024 Received: from localhost ([127.0.0.1]:43121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tFil3-00049D-ST for submit <at> debbugs.gnu.org; Mon, 25 Nov 2024 18:44:46 -0500 Received: from mail-wr1-f51.google.com ([209.85.221.51]:58558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1tFil2-000495-0x for 74413 <at> debbugs.gnu.org; Mon, 25 Nov 2024 18:44:44 -0500 Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-3823e45339bso3716619f8f.0 for <74413 <at> debbugs.gnu.org>; Mon, 25 Nov 2024 15:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732578223; x=1733183023; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=H9gsgMMAo4ZSB/rvVvbxM22VpeLGZ9pzs0CKLx+x1jU=; b=BcGEfZWBV2tt8pKUk8//8nuVa1wo+EaOjMFh7NGN7mm+1HYfjSwPNPCm+D6yOOD2Ed tk26eHqgqvU1jKSnst3JCD+7xGEt1X3NLEJte9W2ABYV/1ywvxkpy7BOP8ddEW6h2G9V cl/XPKaOngLQAhrL7InV75FAsjJBp0alIRMBNgOG6xZdVGFH81jSC6jPnkO7AT5LUVQ3 nGb3SgzAARs6oa9hucd6cTR1CpbohLLfh/x7es5EPgP4ptM53Hr7cnlY72tW3b+ODJx+ zch+2QCvlhcwpTGBQ1Jcomab7kEYiMW9r/jYvdnAto8z2hVmwGiNa9Qp/PSFjhdF7KBt 2i9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732578223; x=1733183023; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=H9gsgMMAo4ZSB/rvVvbxM22VpeLGZ9pzs0CKLx+x1jU=; b=OzOyMJTlx5tBEdHE7HyQECcGFL3OgrND73kTGXhGv46JaHRcaYwDADESQ2LAD/6PDs diDBZSX5GdOQwJioTC0o58oOzH43hWO5Yw/48uKXgNf7aJsVXwlhznxqNr18Kz4kA8+f kltmNbIXsDMA8O51lhhsUE8V7gt1b+0wOCaARDnJFY3a6cvdLs2vYe+1LWfeosDD+Sf0 XZNC8vETlZKq59BHlNtqWAzTMxeLRhXLe4vCu1/LzDEEgZqeVERQRDdAHUkADW4NNt1l P/O8lKyfa6k2xZY5iIIgE+IuCJqngawvvf7lZ+G7WqhT+KwVEVoRphtjhBJXgCfqu19n 8xgA== X-Forwarded-Encrypted: i=1; AJvYcCUBfUHjqr/X1C1Wrt3Ui5jtdSPLiQn2ns0vxf/0C9CFLdIEJv74Y+D5OhNHx44gPq23Nuu0Xw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YztKVQlnjbdU8FD9xe6dMxSmi+AsvCnXh8Zn8EVuguDtDFC8Ypl X5e5306iBcbZFrYeGEOXZcyZ5PeO5YHpJ+8O+o3dM1T1T6UL+rpwXbZEFypPlyemeLVWtTAxIAt lk1OOug4Z6hTM/jP3bwpPpIyo4w0= X-Gm-Gg: ASbGncudADgKhOz/QP1a7JtbwbxxrUVszoIFZJ8k5lUS5G98DM45JgLaH0qqxiPtTeW e54HN/0NbuEaTJ10XeS16gVtCJce1GqqEWQ== X-Google-Smtp-Source: AGHT+IEWWK/ebB4E8dnwt8c8FZtcwDNAQcV3cFbdN2MRUr4YQhVVL+J5+zJh+Fr/gX6dmjl0gf0DF2vvdeHMdsMKGks= X-Received: by 2002:a05:6000:2ae:b0:382:498a:9cec with SMTP id ffacd0b85a97d-38260b5cf52mr12235219f8f.13.1732578222545; Mon, 25 Nov 2024 15:43:42 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 25 Nov 2024 15:43:41 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <673c31c6.a70a0220.18f62b.10d8SMTPIN_ADDED_BROKEN@HIDDEN> References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@HIDDEN> <673c31c6.a70a0220.18f62b.10d8SMTPIN_ADDED_BROKEN@HIDDEN> MIME-Version: 1.0 Date: Mon, 25 Nov 2024 15:43:41 -0800 Message-ID: <CADwFkmmpDpf5sE-qFOB5+wFKJ3DpqxdrbhLpT9g3qCXUe=7Eyg@HIDDEN> Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds To: =?UTF-8?B?QmrDtnJuIEJpZGFy?= <bjorn.bidar@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN> writes: >> I don't fully understand how you can have a situation where you can get >> this information in the Makefile, but you can't also get it when dumping >> using `emacs-repository-get-version` and `emacs-repository-get-branch` >> (lisp/loadup.el:474). Could you please elaborate on this? > > I added the Makefile part so it would work outside of my environment if > one builds Emacs and then distributes/install it without the sources or > without them containing the VCS information while git is also installed > in their build environment. I don't think I understand what you're saying here. Is it possible that there are some typos above? I'm thinking of the part that contains the tautology "without the sources or without them". There are also some words where the meaning is not entirely clear to me, such as "distributes" and "installs". Maybe it will be clarified by the answers to my below questions. >> Do you mean that you have one containerized process with Git that clones >> emacs.git into a directory, and then an entirely separate containerized >> process, without Git, builds Emacs from that very same directory? Or >> something along those lines? > > Yes more or less. > I'm using an obs source service that generates a tarball from VCS's and > then creates a tarball. [1] I took a look at the linked documentation, but it seems to be on a very detailed level, and does not provide a good overview. So I don't think I understood much from it. I'm not familiar with the Open Build System, so this is quite hard for me to follow. Please be patient with me. In your description above, could you explain what is the difference between the two steps "generates a tarball from VCS" and "creates a tarball"? Do you mean to say that it: 1) generates a tarball from emacs.git, excluding the .git directory 2) copies that tarball to a completely different environment 3) builds Emacs The part that I do not understand is in which step you run `make`, and how. Is it run in the first step, the third, the first and the third, or something else? Is it run automatically by OBS, or do you have to specify it? Basically, I still don't understand the answer to my below question: >> In this very particular scenario, isn't it enough to add this >> additional step to your CI pipeline: >> >> ./src/emacs -Q --batch --eval '(princ (format "%s:%s" \ >> emacs-repository-version emacs-repository-branch))' > version.info > The obs source service already contains that information see the > emacs.obsinfo file I mentioned earlier. Hmm. Would an alternative solution be to read the version information from that file then, if it exists? >> In other words, is it really necessary for us to support this use case >> in our Makefile? Do we expect that building Emacs in such CI pipelines >> using non-released development version of Emacs will be very common? > > The Makefile target is there already for the Android builds all I did I > added it to other platforms too. If the target would be shared then the > hole process is reused. If we want this for other builds, then reusing what we do for the Android build sounds prudent. It is clear that this is needed for Android. What remains to clarify is why it is needed elsewhere. > I think it would become more common to build from VCS sources would be > become more common where the information is useful. Building from VCS sources is already quite common. I'm asking something more specific: will it be increasingly common to build using an environment very similar to OBS? If it is not going to be very common, this should perhaps be fixed in the OBS pipeline directly, instead of complicating our Makefile. But I'm not yet clear on whether that is true. > To get more users to test earlier development builds to have faster > general feedback and bug reports reports it is very useful to have > non-released development builds. There are other instances outside my > own usecase where this is frequent such as for example the AUR emacs-git,= guix > emacs-next or the Android Fdroid builds. Are you saying that AUR emacs-git, guix emacs-next, and the Android Fdroid builds also have no way to know which revision Emacs was built from without your patch? >> BTW, what is the name of that CI system that you're using here? For >> what purpose are you building Emacs: to test Elisp packages, to test >> Emacs, or something else? Finally, why are you not using officially >> tagged versions, either from us or from some distro, in this context? > > I'm build Emacs on the open build service. I'm building Emacs on the obs > to provide development builds that can be used to test Emacs and submit > bug reports. > The package is build using the official RPM packaging just > with the newer sources from git. > > The initial reason reason was that I noticed that even if you build from > git directly without a CI/or something similar to the source service > mentioned earlier that the functions to retrieve the repository > information don't work since the source path either doesn't exist on any > the machine that installs the final package or that it doesn't contain > the VCS information anymore. > The setup is very similar to the Android builds. Thanks.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.
Received: (at 74413) by debbugs.gnu.org; 20 Nov 2024 07:55:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 20 02:55:30 2024
Received: from localhost ([127.0.0.1]:45084 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tDfYf-0005kq-Ue
for submit <at> debbugs.gnu.org; Wed, 20 Nov 2024 02:55:30 -0500
Received: from thaodan.de ([185.216.177.71]:34018)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bjorn.bidar@HIDDEN>) id 1tDfYc-0005kh-Kz
for 74413 <at> debbugs.gnu.org; Wed, 20 Nov 2024 02:55:27 -0500
Received: from odin (dsl-trebng12-50dc7b-49.dhcp.inet.fi [80.220.123.49])
by thaodan.de (Postfix) with ESMTPSA id 9364AD00077;
Wed, 20 Nov 2024 09:55:23 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail;
t=1732089323; bh=cdVVl/6/OUOV+rGXCjQGA7aPthgruNFN6uRsQpiUBdQ=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=BBB86yOUVstOh8rAxr65aXgFbfKJWEI1GPAkyb64Yf5mxTsJML/pVY/WtIgRYD7sq
ShXakN++6/SpO3VN5aldlBO2QTv0n6LuigRlsmQmQLhQZrvOVwE7rVPYTHxVx6d1ph
NlxnlDuB3/JzAhE6/Oi4aFYkutmYV8qfUN59UMpBAqIWWxXKoTNhIRnoYmWlYIQmFe
icWww7VtPwnxJSdJJgaHXrzp8HK9xTva43nc6IVPF01ZoEpQkUIjAR/vXkhHrGjhuR
2Ztuxa2FyK2YJYdySKa+zBUfig4pDPz+I7cEVlEzmMuN7iekRnXG8BCXidIASUMKsB
M/YI60ag28URbLseSXhfcx0vkUK9Yxyn8VIh/h3SHXcVIbZ7stXF77DOy6sIOYuQ3h
+gDI6byESbvvH7aGPjtuy4CzqldSvGFDv49USUUhz1IZXz8+dV+6vsE6tRtDuOflXx
pOg7qUVHrj0Xa3qNQSssrs1P1ht0aAsBYJOQxF3cRmd9Xp4dI8O/tL89YRvCTJtWku
UoTeibeakeXw6Of7X/f/ktnuKRcnVp75/93/aCj3OcBHM2HBd6bkaTmJBSwEHEGmMw
spcesfKCzFk5QK8bVb/ZWXAkpr9pLZCQc4dp7lNheRShR0TyWSMDf1emYDX3Ty4E6Q
ujlfAHC8xLPTxuQCoFkCbACE=
From: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#74413: [PATCH] Allow to store and read repository
information of VCS builds
In-Reply-To: <86frnntalh.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 19 Nov
2024 19:08:42 +0200")
References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN>
<861pz8uzyo.fsf@HIDDEN> <86zflwtjlz.fsf@HIDDEN> <86wmgztfse.fsf@HIDDEN>
<87ttc3td5x.fsf@HIDDEN> <86frnntalh.fsf@HIDDEN>
Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq
w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV
CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl
HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8
phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF
CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h
K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2
cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC
HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN
XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg
gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL
AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E
TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB
B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe
pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO
HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG
AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr
dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n
KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy
GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK
S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA==
Date: Wed, 20 Nov 2024 09:55:22 +0200
Message-ID: <87h682tk45.fsf@>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii <eliz@HIDDEN> writes: >> From: Björn Bidar
<bjorn.bidar@HIDDEN> >> Cc: stefankangas@HIDDEN, luangruo@HIDDEN,
74413 <at> debbugs.gnu.org >> Date: Tue, 19 Nov 2024 18:13:14 +0200 >> >> >> If
the source is generated by [...]
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in bl.score.senderscore.com]
0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
The query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in sa-trusted.bondedsender.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 INVALID_MSGID Message-Id is not valid, according to RFC 2822
X-Debbugs-Envelope-To: 74413
Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN>
>> Cc: stefankangas@HIDDEN, luangruo@HIDDEN, 74413 <at> debbugs.gnu.org
>> Date: Tue, 19 Nov 2024 18:13:14 +0200
>>=20
>> >> If the source is generated by the CI it can also store this informati=
on
>> >> in the build source which then can be extracted from the ci metadata =
to
>> >> the Emacs sources on the builder.
>> >>=20
>> >> I can be sure that Emacs was built from that revision as much as I can
>> >> trust the CI to use the sources I told it to use. If I can't trust on=
e,
>> >> I can't trust the other.
>> >
>> > But CI builds from Git, doesn't it? If so, the Emacs it produces
>> > already records the revision and the branch.
>>=20
>> The source generator, the source service runs git but the builder
>> doesn't.
>> Because the builder doesn't have to deal with git the rebuild chain is
>> smaller, build dependency changes can trigger rebuilds, and the worker
>> doesn't have to have git installed.
>>=20
>> In most cases it's not required or wanted that worker have git as the
>> only allowed purpose would be to get access already existing metadata but
>> not change anything on the sources itself.
>>=20
>> Providing the metadata to the VCS emacs-repository-branch and
>> emacs-repository-version with the previously generated metadata that
>> belongs to the package sources removes the need for git in the build wor=
ker.
>
> Thanks, but I still don't understand the problem you are trying to
> solve. I guess I'm missing something very fundamental here. You are
> talking about "builder", "source generator", "metadata", etc., and I
> don't understand these terms. The last sentence seems to confirm my
> guess: you tage the Git revision from a repository, and then build
> from another directory, which can easily cause a mismatch.
It could be that I either assume some things or don't explain them well eno=
ugh.
I generate a tarball from one repository, store the last commit's refernce =
the
snapshot of that repository which the tarball was generated from.
The configuration of the program that generates the tarball contains the
branch it pulls the sources from. Both of these then are put into the
the same file that is used by the Android builds.
> So this
> feature looks completely redundant to me, based on the little I do
> understand in these matters. But I will now bow out of this
> discussion; if Stefan (and others) think it's okay, I won't object.
To reduce any possible I could make the make target shared with the
Android builds if that helps.
> Thank you for your patience.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Received: (at 74413) by debbugs.gnu.org; 19 Nov 2024 17:20:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 19 12:20:52 2024 Received: from localhost ([127.0.0.1]:43881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tDRuG-0000Cw-2k for submit <at> debbugs.gnu.org; Tue, 19 Nov 2024 12:20:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tDRuE-0000Ck-IP for 74413 <at> debbugs.gnu.org; Tue, 19 Nov 2024 12:20:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1tDRu7-0003KG-WF; Tue, 19 Nov 2024 12:20:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=WUNq72WqslaxTcITBdDRHTDNC49XGLGR6YTIGgeeBEE=; b=eCnd/6ZwcU4o7PcBAUfn M/zb+qDxFTrV2CF8pEOzDWBwXNW/5m8/O0KppSaqjRmcMi6OfRkkSp4iMFFtOrIlc7o5bo7WlyuhJ LI+Hzl7/Hk7ogmJjxddJHKWpTo8iFLacdTqgdPrjAnx3wQf3bb3xFSDwozTZWy6VGWo9ZkOiN4nAr DWZHWrQwGNNSeXVyroTnnHjk7r71hZdFfDgP2lkrNl3rOVci8Wa6tYBqL2ZBWzrSV/9BztWSNrKmD 5gT0j6MKxaKJpWlB0LZ3fuoo5wLFyAmKQBmDGAkdpV14KvTL7R+hC3qYWDJmrx48vW0cpE3eYW10s 9lns84si4cBgzQ==; Date: Tue, 19 Nov 2024 19:20:42 +0200 Message-Id: <868qtfta1h.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?iso-8859-1?Q?Bj=F6rn?= Bidar <bjorn.bidar@HIDDEN> In-Reply-To: <87plmrtd0j.fsf@HIDDEN> (message from =?iso-8859-1?Q?Bj?= =?iso-8859-1?Q?=F6rn?= Bidar on Tue, 19 Nov 2024 18:16:28 +0200) Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@HIDDEN> <86v7wjtfms.fsf@HIDDEN> <87plmrtd0j.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Bidar <bjorn.bidar@HIDDEN> > Cc: Stefan Kangas <stefankangas@HIDDEN>, luangruo@HIDDEN, > 74413 <at> debbugs.gnu.org > Date: Tue, 19 Nov 2024 18:16:28 +0200 > > > Yes, I still don't understand the utility of this feature, since it > > needs Git for producing the information in the file. > > As explained Git doesn't have to be installed using that feature on the > machine that executes the built Emacs or on the builder. Yes, and I don't understand the utility of this.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Received: (at 74413) by debbugs.gnu.org; 19 Nov 2024 17:08:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 19 12:08:56 2024 Received: from localhost ([127.0.0.1]:43859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tDRii-00085G-8c for submit <at> debbugs.gnu.org; Tue, 19 Nov 2024 12:08:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tDRif-000852-5Q for 74413 <at> debbugs.gnu.org; Tue, 19 Nov 2024 12:08:53 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1tDRiY-0000ZV-VH; Tue, 19 Nov 2024 12:08:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=19k/4vtgPd580V5Z6fYZviWYwGCw7w3Q+R2qwDXK5Rs=; b=Jmk2BMFRdKzDUaplrctG +rjHUvCvpkO/K91L2HrdukCUqLRrF2ts68CviV6fsVgD0gWZk6LEJf8hIa5ViHK4q/ZywF9sP1x2q SnqLhv08pQv9QxkLq4rHhkrffs12eR7W7v9PhDUZDPGbf+NR0sfnEOpujEG3zdX+ywHmcfp9/DR9Z gjBqHtpJ/TCdza9tVtk7oiKikkTafFBCGcHyoE3rR9BhU+ctu3mSGJdpqlB35kADd77+Ud8X5beYB NVlRaPl7CTDXp9aV2IzRRI+1TZdPgYo2FopXRcNJnWiLr+j+GYP0CxFTgGlMsw1/4MZOXNJt2ZKtU HVjb6GLTYnpn2w==; Date: Tue, 19 Nov 2024 19:08:42 +0200 Message-Id: <86frnntalh.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN> In-Reply-To: <87ttc3td5x.fsf@HIDDEN> (message from =?utf-8?Q?Bj=C3=B6r?= =?utf-8?Q?n?= Bidar on Tue, 19 Nov 2024 18:13:14 +0200) Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <861pz8uzyo.fsf@HIDDEN> <86zflwtjlz.fsf@HIDDEN> <86wmgztfse.fsf@HIDDEN> <87ttc3td5x.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Bidar <bjorn.bidar@HIDDEN> > Cc: stefankangas@HIDDEN, luangruo@HIDDEN, 74413 <at> debbugs.gnu.org > Date: Tue, 19 Nov 2024 18:13:14 +0200 > > >> If the source is generated by the CI it can also store this information > >> in the build source which then can be extracted from the ci metadata to > >> the Emacs sources on the builder. > >> > >> I can be sure that Emacs was built from that revision as much as I can > >> trust the CI to use the sources I told it to use. If I can't trust one, > >> I can't trust the other. > > > > But CI builds from Git, doesn't it? If so, the Emacs it produces > > already records the revision and the branch. > > The source generator, the source service runs git but the builder > doesn't. > Because the builder doesn't have to deal with git the rebuild chain is > smaller, build dependency changes can trigger rebuilds, and the worker > doesn't have to have git installed. > > In most cases it's not required or wanted that worker have git as the > only allowed purpose would be to get access already existing metadata but > not change anything on the sources itself. > > Providing the metadata to the VCS emacs-repository-branch and > emacs-repository-version with the previously generated metadata that > belongs to the package sources removes the need for git in the build worker. Thanks, but I still don't understand the problem you are trying to solve. I guess I'm missing something very fundamental here. You are talking about "builder", "source generator", "metadata", etc., and I don't understand these terms. The last sentence seems to confirm my guess: you tage the Git revision from a repository, and then build from another directory, which can easily cause a mismatch. So this feature looks completely redundant to me, based on the little I do understand in these matters. But I will now bow out of this discussion; if Stefan (and others) think it's okay, I won't object. Thank you for your patience.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Received: (at 74413) by debbugs.gnu.org; 19 Nov 2024 16:17:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 19 11:17:04 2024 Received: from localhost ([127.0.0.1]:43778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tDQuW-0005rQ-K2 for submit <at> debbugs.gnu.org; Tue, 19 Nov 2024 11:17:04 -0500 Received: from thaodan.de ([185.216.177.71]:50826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <bjorn.bidar@HIDDEN>) id 1tDQuU-0005rH-W2 for 74413 <at> debbugs.gnu.org; Tue, 19 Nov 2024 11:17:03 -0500 Received: from NordStern (unknown [185.252.118.71]) by thaodan.de (Postfix) with ESMTPSA id E1409D00038; Tue, 19 Nov 2024 18:16:28 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1732032989; bh=6REoBNgu8KQFmEdTG+CnR5x4xCoBjpMXxVzahYYoMa8=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=s1oh4JAIIewBgOXnzsxAZmNzsAEs+pe8jphIspu7fu2p40wac1/xFl+Qnos4z6Fqf jR3utflK09x6GsxrbL6H5aGKHN62s57Qtc1N4GuyF2yFCRK/r8sw6SA8afP1t6wlj3 AJ62gqhxu5cUIBh/CJshb3eONr4Vdzr/+KCUZORqcW7fEcK9F7zFhntscCGUcAP+LL HD/ZlsJXtBXzxPPOHNj9lgsgZVg771xmNwWVHXck5j/EAKg6uR7aaKBZdMRYpkz+uH VqF0cbJL/HZRpXrKUapFJYV8HQA8xn1O9B2CNUZGExQzfKTqqqP6zqpKpD4oWQb82K NpnPRvcNho9QuR3zDs2KArC9XDKuWM04yTfSIS364YrtRT9P5VVvd00b4qvW5o2hR2 7c5pZ1uwFW64KA4d0Xfc15YO0Z/7jyFgP+M8vIT9/zIbuLC7oAU8g9I9UEAQF3vR+0 qrDaEeq6FYI4M6euJBqD4O9BgVV3RgGxAUpWARUOBSxJhAo9CNvZDrHmDxesF1tLl/ I/4tlm2/qcBCiXXEaLgL06AKEJ9aZdHZglNkPaEkcvW2oWqMuEcfMngQHCkOF4fPJF 4qd8yvkrostxJdTbzkMS6iE915ZA147Hg7BMh4JxjjyZVAfChLL6ub7RHzam36WBx4 zEF03GQwQbfgc6/tt7jEKV6Y= From: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds In-Reply-To: <86v7wjtfms.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 19 Nov 2024 17:19:55 +0200") References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@HIDDEN> <86v7wjtfms.fsf@HIDDEN> Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA== Date: Tue, 19 Nov 2024 18:16:28 +0200 Message-ID: <87plmrtd0j.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, Stefan Kangas <stefankangas@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Stefan Kangas <stefankangas@HIDDEN> >> Date: Mon, 18 Nov 2024 18:48:31 -0500 >> Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> > The branch name could be private. >> > >> > Stefan, WDYT about this feature suggestion? >> >> The privacy risk here is that if a user is building their own private >> branch, announcing the sha or branch name to the world can be used to >> uniquely identify that user. It would be a serious privacy issue if we, >> for example, included that information in User-Agent headers sent by EWW >> or other kinds of network traffic. AFAIK, we don't do that. >> >> IIUC, we use this information only when submitting bug reports. I think >> this is harmless, if we assume privacy threat models where it can also >> be considered safe to report bugs. The few users that have more strict >> privacy requirements, and are eager to report bugs, will just have to >> think about this detail themselves; it's a rather specialized use case. > > AFAIU, the intent is to use this for more than just bug reporting. Where could leak the feature information? If it could it should be adjusted as well for the Android builds. >> I don't fully understand how you can have a situation where you can get >> this information in the Makefile, but you can't also get it when dumping >> using `emacs-repository-get-version` and `emacs-repository-get-branch` >> (lisp/loadup.el:474). Could you please elaborate on this? > > Yes, I still don't understand the utility of this feature, since it > needs Git for producing the information in the file. As explained Git doesn't have to be installed using that feature on the machine that executes the built Emacs or on the builder. The feature is the same as for the Android builds just for other platforms, the reasons are the same as for Android.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Received: (at 74413) by debbugs.gnu.org; 19 Nov 2024 16:13:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 19 11:13:20 2024 Received: from localhost ([127.0.0.1]:43761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tDQqu-0005eZ-2J for submit <at> debbugs.gnu.org; Tue, 19 Nov 2024 11:13:20 -0500 Received: from thaodan.de ([185.216.177.71]:59614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <bjorn.bidar@HIDDEN>) id 1tDQqr-0005eL-5x for 74413 <at> debbugs.gnu.org; Tue, 19 Nov 2024 11:13:18 -0500 Received: from NordStern (unknown [185.252.118.71]) by thaodan.de (Postfix) with ESMTPSA id 72464D00038; Tue, 19 Nov 2024 18:13:15 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1732032795; bh=CWAMKdrpuPTUR+G0w13NEdzoypUzS6qXT6B265ETCxE=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=wgjHQlrqabYIFsbvveod6+0Idvh1LjUx9Cs9H1jEcPrWyvA88U33CPMINgaRmzarK Mggis+fL0LHvLBZYk54PfxNC5C4C1brMzhYS24UyS7O+uCl3tJVZjqmINcX/LQ79eB 9wyj9+PtP3zxbwz3QRP5x2PzKZ4AsivjK90U/J2+0UF9rmd1fqWPAg4v95EpD+R9cs UtlLcqq4gDMX7v3vEB2h/jCvQhVVIzyPD2r4LLDLTzX+etyWmnXK2JX1r1VzSvbHxc WYue91mb4I86ZrFwh6Bm0ENvLMyKMQBbt53TKe/6g51n5tdsFQLAmALI/10wvs/fmh dGHUqTuronZzBT/YJaT2exKdFZkOzztEYVLzrw7Ifkmrr2KP15G+eBKH6sro09W5h/ QJFP+tGihwvfgQxo50jhXFfh5hhlbXbTEQccC9M5Ig3EpiTN7mtoYF8H2tPFHM6kfj T5/A4mMyjq1Xl13Iq9fXeSRBwD5XtimEer3jrKzMxzqM/kYm3pTZckha3DTy7+yyA6 WjmlWbR7ZWwRGeoyztkGcOqHp/3tUOX6dcC97kueKwFYlImy9vBQeLWWGj67dnWw7f V7L2TBYF8NOueSbFUz2PEHdNkuWbaRg3PSxwDDGOh69SvPctpvl2XS8POTHICafVfZ T6FwUMnDyQLEWB9pTqZVvGso= From: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds In-Reply-To: <86wmgztfse.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 19 Nov 2024 17:16:33 +0200") References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <861pz8uzyo.fsf@HIDDEN> <86zflwtjlz.fsf@HIDDEN> <86wmgztfse.fsf@HIDDEN> Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA== Date: Tue, 19 Nov 2024 18:13:14 +0200 Message-ID: <87ttc3td5x.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN> >> Cc: stefankangas@HIDDEN, luangruo@HIDDEN, 74413 <at> debbugs.gnu.org >> Date: Mon, 18 Nov 2024 23:48:38 +0200 >>=20 >> Eli Zaretskii <eliz@HIDDEN> writes: >>=20 >> > I still don't think I understand, sorry. Do you mean the file is >> > generated from a Git repository, but then Emacs is somehow built from >> > a directory that is not under Git? >>=20 >> The file can be generated from the git repository outside of the Emacs >> builder. > > So you mean someone will chdir to the Git repository, say > > $ make etc-emacsver > > Then take the produced file and manually install it when Emacs is > built (in another directory) and installed, is that right? I extract the file from the obs service and generate file from the services metadata. The make target is there to create the file if Emacs is built with git installed or if the target is used in the way you mentioned above.=20 In both cases the emacs VCS functions will still work after the built without the sources or git installed, in the case of the former as long as in the packager has provided the metadata themselves.=20 >> > But if this is the scenario, how can you be sure the produced Emacs bi= nary was made from that revision >> > on that branch? This is only guaranteed if you actually build from >> > Git when you record this information. >> > >> > What am I missing? >>=20 >> If the source is generated by the CI it can also store this information >> in the build source which then can be extracted from the ci metadata to >> the Emacs sources on the builder. >>=20 >> I can be sure that Emacs was built from that revision as much as I can >> trust the CI to use the sources I told it to use. If I can't trust one, >> I can't trust the other. > > But CI builds from Git, doesn't it? If so, the Emacs it produces > already records the revision and the branch. The source generator, the source service runs git but the builder doesn't. Because the builder doesn't have to deal with git the rebuild chain is smaller, build dependency changes can trigger rebuilds, and the worker doesn't have to have git installed. In most cases it's not required or wanted that worker have git as the only allowed purpose would be to get access already existing metadata but not change anything on the sources itself. Providing the metadata to the VCS emacs-repository-branch and emacs-repository-version with the previously generated metadata that belongs to the package sources removes the need for git in the build worker.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Received: (at 74413) by debbugs.gnu.org; 19 Nov 2024 15:20:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 19 10:20:37 2024 Received: from localhost ([127.0.0.1]:43659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tDQ1t-0003FY-5i for submit <at> debbugs.gnu.org; Tue, 19 Nov 2024 10:20:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tDQ1r-0003FK-PC for 74413 <at> debbugs.gnu.org; Tue, 19 Nov 2024 10:20:36 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1tDQ1j-0006M8-Ed; Tue, 19 Nov 2024 10:20:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tFrzFU/wMbijF1yLQecEaTXcwE7N6JoxFeDA+Xfd/sQ=; b=OUa8DApVq7NB Jpg0EOUfDOMATBDkixfoI+574WDiUPLKLypfTUe8wYtUfGy7Ua9/Tl6OHQDh7ZoV04smwo4YBhDqZ lwkqjI1Rh7i0588EN0fOyctGFZWCg+4lI7gqsu0Ik95uNR4JuroEarZ57RCfAK1lESdt8RfPXTz53 j4vK6+Az51lX6c5/GRSBFXWdFyrFXQULMs4t/y0Vuxfsa8ATv6dUSP0fUovUDmEhW106n0mqStYPb qPKJTlm2+w1l5AzPOfYmXzGxQttADZ2ya3WtZ5iH1VOua+cyjV/BQ9/Cc927wYSNsdPOFuQ++QhvS yAg+PvRkb4RG4AzEp44sDg==; Date: Tue, 19 Nov 2024 17:19:55 +0200 Message-Id: <86v7wjtfms.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@HIDDEN> (message from Stefan Kangas on Mon, 18 Nov 2024 18:48:31 -0500) Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, bjorn.bidar@HIDDEN, 74413 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Kangas <stefankangas@HIDDEN> > Date: Mon, 18 Nov 2024 18:48:31 -0500 > Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org > > Eli Zaretskii <eliz@HIDDEN> writes: > > > The branch name could be private. > > > > Stefan, WDYT about this feature suggestion? > > The privacy risk here is that if a user is building their own private > branch, announcing the sha or branch name to the world can be used to > uniquely identify that user. It would be a serious privacy issue if we, > for example, included that information in User-Agent headers sent by EWW > or other kinds of network traffic. AFAIK, we don't do that. > > IIUC, we use this information only when submitting bug reports. I think > this is harmless, if we assume privacy threat models where it can also > be considered safe to report bugs. The few users that have more strict > privacy requirements, and are eager to report bugs, will just have to > think about this detail themselves; it's a rather specialized use case. AFAIU, the intent is to use this for more than just bug reporting. > I don't fully understand how you can have a situation where you can get > this information in the Makefile, but you can't also get it when dumping > using `emacs-repository-get-version` and `emacs-repository-get-branch` > (lisp/loadup.el:474). Could you please elaborate on this? Yes, I still don't understand the utility of this feature, since it needs Git for producing the information in the file.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Received: (at 74413) by debbugs.gnu.org; 19 Nov 2024 15:18:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 19 10:18:56 2024 Received: from localhost ([127.0.0.1]:43649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tDQ0F-00036n-K1 for submit <at> debbugs.gnu.org; Tue, 19 Nov 2024 10:18:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50086) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tDQ0D-00036a-AF for 74413 <at> debbugs.gnu.org; Tue, 19 Nov 2024 10:18:54 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1tDPy0-0005ZT-J5; Tue, 19 Nov 2024 10:16:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=d7kPo19Z7emfvEn6eVoqh+ITcM1ifOzXUOPMIOgWzhg=; b=Bdg442JGEDvNcRzibyIp mpS0U+92eojmazarfEWIADVcepJSFtWbKXko34LlRXyhNhcHKeahDclYndogXPvBTiw097txnR/h/ /dRXNxLMua1fMGpCp/VV0m0c/8vsfSNTI/eqLi68P56zOixnbGNH+3c1eskFx8db2zbkhrRYvj27X U03rH/jfCkcc8yqbM3282aA5kykbUcoNpS/mpbtiQWezByUJflV18rT2/YKL/J1B2e0hzjDIP+IsR kkqRTl4l4X3Q9GE6CHuhb/TzTcx6WOPaYjpefO1IkXIBSL9kYa315bDHV7hNm4Vhmd7SLb1jK27kJ bGQucXRa+0eMmw==; Date: Tue, 19 Nov 2024 17:16:33 +0200 Message-Id: <86wmgztfse.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN> In-Reply-To: <87y11g5i2x.fsf@> (message from =?utf-8?Q?Bj=C3=B6rn?= Bidar on Mon, 18 Nov 2024 23:48:38 +0200) Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <861pz8uzyo.fsf@HIDDEN> <86zflwtjlz.fsf@HIDDEN> <87y11g5i2x.fsf@> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Bidar <bjorn.bidar@HIDDEN> > Cc: stefankangas@HIDDEN, luangruo@HIDDEN, 74413 <at> debbugs.gnu.org > Date: Mon, 18 Nov 2024 23:48:38 +0200 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > I still don't think I understand, sorry. Do you mean the file is > > generated from a Git repository, but then Emacs is somehow built from > > a directory that is not under Git? > > The file can be generated from the git repository outside of the Emacs > builder. So you mean someone will chdir to the Git repository, say $ make etc-emacsver Then take the produced file and manually install it when Emacs is built (in another directory) and installed, is that right? > > But if this is the scenario, how can you be sure the produced Emacs binary was made from that revision > > on that branch? This is only guaranteed if you actually build from > > Git when you record this information. > > > > What am I missing? > > If the source is generated by the CI it can also store this information > in the build source which then can be extracted from the ci metadata to > the Emacs sources on the builder. > > I can be sure that Emacs was built from that revision as much as I can > trust the CI to use the sources I told it to use. If I can't trust one, > I can't trust the other. But CI builds from Git, doesn't it? If so, the Emacs it produces already records the revision and the branch.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.
Received: (at 74413) by debbugs.gnu.org; 19 Nov 2024 06:36:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 19 01:36:28 2024
Received: from localhost ([127.0.0.1]:40368 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tDHqe-0004Ad-5h
for submit <at> debbugs.gnu.org; Tue, 19 Nov 2024 01:36:28 -0500
Received: from thaodan.de ([185.216.177.71]:35898)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bjorn.bidar@HIDDEN>) id 1tDHqZ-0004AP-0w
for 74413 <at> debbugs.gnu.org; Tue, 19 Nov 2024 01:36:26 -0500
Received: from odin (dsl-trebng12-50dc7b-49.dhcp.inet.fi [80.220.123.49])
by thaodan.de (Postfix) with ESMTPSA id 949D9D00030;
Tue, 19 Nov 2024 08:35:49 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail;
t=1731998149; bh=vSBNnwKfxkScwKWdTM86775akROSrPbCPb4ko/tPJhg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=F64hFL4B18DkURw96rd37jfNIdgh00c2lpU/sSzZENWvEhDpdXOH6hL0V+WgpxOcO
/hQEtdTMu+QkB7JcepScyjzgj/5hfXm8BJTYoIljzOnhlYo8dwXIFC9/hmaGkPGO5c
5i7WGQwxRjnXstix0aQnbZrA7lPuwqW0n4Z43CIViNzV+tJsMZA/bGzHMpDPPXb7p5
A/R93oRA0AV8lt7Ur5eOuDnfQSPMRIuzxowLBb8uYLZpKG53lVho+20tr287iiO93X
PjRw7qWxSIggzBcw9tDMpQaiptkJRv1aiPl4EX9al/xldCoW3KLHwmm5hjXiykf7sR
CLy9Ns1/Q+VmUPROltkJYeB8ITDvPlQQKGSpvSc3k+jIXOAfxAoC6ocITxXHHzhqJx
vqgdC7VuydNE/wV9DTFWZqlL2Rn1pGZlTG2QNkiwoFVHo5evnlB6JYFGMPVq8r5573
Ra5HjboR9KyxescYpluKMfA3q3CHZkhNHwYGQ/ZSb24jW3bNdWOBvfkKTIyq6oj0Ek
Dc43AADLRUaPODdAao0aVO3srF8aHJkE5xBWhm8xAjuUzDkce0yuvJxigaUzLxpUzl
Q2ZS9BMKd5yEwz97FEtukMEp2Pq5ZRtaLE0fZQWR+EHJ0Qy+t4sxq52Ahh5XVOiF5r
qOSpaU5+v5/VLZnXs2UVVaP0=
From: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
To: Stefan Kangas <stefankangas@HIDDEN>
Subject: Re: bug#74413: [PATCH] Allow to store and read repository
information of VCS builds
In-Reply-To: <CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@HIDDEN>
(Stefan Kangas's message of "Mon, 18 Nov 2024 18:48:31 -0500")
References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN>
<CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@HIDDEN>
Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq
w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV
CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl
HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8
phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF
CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h
K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2
cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC
HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN
XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg
gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL
AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E
TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB
B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe
pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO
HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG
AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr
dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n
KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy
GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK
S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA==
Date: Tue, 19 Nov 2024 08:35:48 +0200
Message-ID: <87plmru3wb.fsf@>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Stefan Kangas <stefankangas@HIDDEN> writes: > Eli Zaretskii
<eliz@HIDDEN> writes: > >>> From: Björn Bidar <bjorn.bidar@HIDDEN>
>>> Cc: Po Lu <luangruo@HIDDEN>, 74413 <at> debbugs.gnu.org >>> Date: Mon, 18
Nov 2024 16:21:28 +0200 >>> >>> > D [...]
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
The query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in sa-trusted.bondedsender.org]
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in bl.score.senderscore.com]
1.2 INVALID_MSGID Message-Id is not valid, according to RFC 2822
X-Debbugs-Envelope-To: 74413
Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)
Stefan Kangas <stefankangas@HIDDEN> writes:
> Eli Zaretskii <eliz@HIDDEN> writes:
>
>>> From: Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN>
>>> Cc: Po Lu <luangruo@HIDDEN>, 74413 <at> debbugs.gnu.org
>>> Date: Mon, 18 Nov 2024 16:21:28 +0200
>>>
>>> > Doesn't that go against the tendency to have _less_ detailed/private
>>> > information in the build? We've lately removed some relatively useful
>>> > infos from what we report in commands that use the build information.
>>>
>>> The information added is only the branch and the repository similarly as
>>> used by the Android builds. There's no private information there unless
>>> the exact change reference Emacs was built on is private.
>>
>> The branch name could be private.
>>
>> Stefan, WDYT about this feature suggestion?
>
> The privacy risk here is that if a user is building their own private
> branch, announcing the sha or branch name to the world can be used to
> uniquely identify that user. It would be a serious privacy issue if we,
> for example, included that information in User-Agent headers sent by EWW
> or other kinds of network traffic. AFAIK, we don't do that.
>
> IIUC, we use this information only when submitting bug reports. I think
> this is harmless, if we assume privacy threat models where it can also
> be considered safe to report bugs. The few users that have more strict
> privacy requirements, and are eager to report bugs, will just have to
> think about this detail themselves; it's a rather specialized use case.
>
> IOW, I don't think I see a reason to object on these grounds.
>
> Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN> writes:
>
>> The additions to the make file are so that if the worker contains git
>> the file can be generated so that the related functions will still work
>> after the built or to generate them prior the built. The latter probably
>> makes less sense except to maybe avoid having autotools in the built
>> dependency chain.
>>
>> If the Make recipe isn't used to generate the version file it can be
>> generated by the CI, e.g. in my case I take the information from the
>> open build source service. For others such as Fedora the sources can be
>> retrieved in a similar manner.
>>
>> The file can be added before the built starts and package so that the p=
dump
>> will contain the repository information and the VCS function will also
>> work afterwards.
>
> I don't fully understand how you can have a situation where you can get
> this information in the Makefile, but you can't also get it when dumping
> using `emacs-repository-get-version` and `emacs-repository-get-branch`
> (lisp/loadup.el:474). Could you please elaborate on this?
I added the Makefile part so it would work outside of my environment if
one builds Emacs and then distributes/install it without the sources or
without them containing the VCS information while git is also installed
in their build environment.
Since Emacs Makefiles already have that target for the Android build it
could make sense to share this target outside of the Android build.
> Do you mean that you have one containerized process with Git that clones
> emacs.git into a directory, and then an entirely separate containerized
> process, without Git, builds Emacs from that very same directory? Or
> something along those lines?
Yes more or less.
I'm using an obs source service that generates a tarball from VCS's and
then creates a tarball. [1]=20
> In this very particular scenario, isn't it enough to add this
> additional step to your CI pipeline:
>
> ./src/emacs -Q --batch --eval '(princ (format "%s:%s" \
> emacs-repository-version emacs-repository-branch))' > version.info
The obs source service already contains that information see the
emacs.obsinfo file I mentioned earlier.
> In other words, is it really necessary for us to support this use case
> in our Makefile? Do we expect that building Emacs in such CI pipelines
> using non-released development version of Emacs will be very common?
The Makefile target is there already for the Android builds all I did I
added it to other platforms too. If the target would be shared then the
hole process is reused.
I think it would become more common to build from VCS sources would be
become more common where the information is useful.
To get more users to test earlier development builds to have faster
general feedback and bug reports reports it is very useful to have
non-released development builds. There are other instances outside my
own usecase where this is frequent such as for example the AUR emacs-git, g=
uix
emacs-next or the Android Fdroid builds.
> BTW, what is the name of that CI system that you're using here? For
> what purpose are you building Emacs: to test Elisp packages, to test
> Emacs, or something else? Finally, why are you not using officially
> tagged versions, either from us or from some distro, in this context?
I'm build Emacs on the open build service. I'm building Emacs on the obs
to provide development builds that can be used to test Emacs and submit
bug reports.
The package is build using the official RPM packaging just
with the newer sources from git.
The initial reason reason was that I noticed that even if you build from
git directly without a CI/or something similar to the source service
mentioned earlier that the functions to retrieve the repository
information don't work since the source path either doesn't exist on any
the machine that installs the final package or that it doesn't contain
the VCS information anymore.
The setup is very similar to the Android builds.
---
[1] https://github.com/openSUSE/obs-service-tar_scm
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.
Received: (at 74413) by debbugs.gnu.org; 18 Nov 2024 23:49:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 18 18:49:35 2024
Received: from localhost ([127.0.0.1]:39735 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tDBUs-0001mm-Ua
for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 18:49:35 -0500
Received: from mail-ed1-f43.google.com ([209.85.208.43]:61848)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stefankangas@HIDDEN>) id 1tDBUr-0001md-BT
for 74413 <at> debbugs.gnu.org; Mon, 18 Nov 2024 18:49:34 -0500
Received: by mail-ed1-f43.google.com with SMTP id
4fb4d7f45d1cf-5cfc19065ffso331320a12.3
for <74413 <at> debbugs.gnu.org>; Mon, 18 Nov 2024 15:49:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1731973712; x=1732578512; darn=debbugs.gnu.org;
h=content-transfer-encoding:cc:to:subject:message-id:date
:mime-version:references:in-reply-to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=6tbhCzqr7pozjRrhVg4gGl/28BiAOSviB4OjIgSG7gw=;
b=lekcWbWNXJ9WDZZDVCq7ZDdE1cPX6/MLQlef9Bfb5iuVcxYLGUkrkAhF6lPO74Xsdp
YFEgsyhlsPYCJYI2MX6K2YZcE4nd80Uoke90RJxr6KFbfW0277coF4ur3X6yFR887lLF
tNRlHnM60KQGUdDAAkeADbZBLOkjvHKr5kZYXhCVB0bdY2l+OkgvJl78APPVFNLDRq5I
v6UfoK5B5qQEPvZaYFF/i5YVDjJ3h7E6DnX+eabkzNq+4Z2nXGKKUGBVAPoOKa2jt2SF
8JuG5Es91yKLTL+kEuqjmFwm3RcOwr9zdli6daVXjLR6WQhSbrI9Fly82lfpFkxx0g72
/ndg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1731973712; x=1732578512;
h=content-transfer-encoding:cc:to:subject:message-id:date
:mime-version:references:in-reply-to:from:x-gm-message-state:from:to
:cc:subject:date:message-id:reply-to;
bh=6tbhCzqr7pozjRrhVg4gGl/28BiAOSviB4OjIgSG7gw=;
b=OEnp0kri1Ou3clK0hFqGEM1DrzM7OxLGRRi4P6tNwlbyeUwtieX6OOhG4/ai4i6Fy2
G9KShgXmdoxupW1SDv1vAnUzbqK5DfrLogUd2UzxJgbEg9AGagJT2QcHCCtr4BkvnqeR
H6nkHtXsDG8PrblTpCMeW72MziYlOa62R7NJ58tac1C4r2BfLeWttm2atwYk880qxtVh
elVJ76NqmIXexVE5+pInYZQmwazjPWJKzPgDfgK2fTB3KzcfuRKruTVVzIy5o9qLyBoI
KufyTa0Zc1pl2dEcr41+/ZqdNrgcpooCzsLiEyMwEjThsCuVetMCuWynr4SdGq34S+2a
1mEQ==
X-Forwarded-Encrypted: i=1;
AJvYcCXc+xJGwWEqxW5Xkrt/s7Sp9YHVBiXa46XfpHNpEwHFGgvtupOnzq1/AgWBbsn/n4svMluoeA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyC724Aqja1e+bAkrrQ4x7a+lf5QGlFOhF1n0rs4/KPv9pDwQBh
J+pTylsG+K7onZKrsK8TCazmBjpPFGh83VV7Hu5L/hcmriHnSIlSbLPasCk0CqxBiY0PxrW+7ma
ttLBOhzqKiI2zg49gw7zjlPR/nas=
X-Google-Smtp-Source: AGHT+IFsJ5Z0kEooQ6+pelQjdbRBZKDCOoBqBuNdAzY/bQuF3pAS60WIiv3f2sish1TSExmrpwJywpUDh2NVNla13fM=
X-Received: by 2002:a05:6402:2787:b0:5cf:c18b:b0ce with SMTP id
4fb4d7f45d1cf-5cfc18bb15dmr4766986a12.14.1731973712153; Mon, 18 Nov 2024
15:48:32 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
HTTPREST; Mon, 18 Nov 2024 18:48:31 -0500
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <867c90vbfk.fsf@HIDDEN>
References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN>
MIME-Version: 1.0
Date: Mon, 18 Nov 2024 18:48:31 -0500
Message-ID: <CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@HIDDEN>
Subject: Re: bug#74413: [PATCH] Allow to store and read repository information
of VCS builds
To: Eli Zaretskii <eliz@HIDDEN>,
=?UTF-8?B?QmrDtnJuIEJpZGFy?= <bjorn.bidar@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 74413
Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN>
>> Cc: Po Lu <luangruo@HIDDEN>, 74413 <at> debbugs.gnu.org
>> Date: Mon, 18 Nov 2024 16:21:28 +0200
>>
>> > Doesn't that go against the tendency to have _less_ detailed/private
>> > information in the build? We've lately removed some relatively useful
>> > infos from what we report in commands that use the build information.
>>
>> The information added is only the branch and the repository similarly as
>> used by the Android builds. There's no private information there unless
>> the exact change reference Emacs was built on is private.
>
> The branch name could be private.
>
> Stefan, WDYT about this feature suggestion?
The privacy risk here is that if a user is building their own private
branch, announcing the sha or branch name to the world can be used to
uniquely identify that user. It would be a serious privacy issue if we,
for example, included that information in User-Agent headers sent by EWW
or other kinds of network traffic. AFAIK, we don't do that.
IIUC, we use this information only when submitting bug reports. I think
this is harmless, if we assume privacy threat models where it can also
be considered safe to report bugs. The few users that have more strict
privacy requirements, and are eager to report bugs, will just have to
think about this detail themselves; it's a rather specialized use case.
IOW, I don't think I see a reason to object on these grounds.
Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN> writes:
> The additions to the make file are so that if the worker contains git
> the file can be generated so that the related functions will still work
> after the built or to generate them prior the built. The latter probably
> makes less sense except to maybe avoid having autotools in the built
> dependency chain.
>
> If the Make recipe isn't used to generate the version file it can be
> generated by the CI, e.g. in my case I take the information from the
> open build source service. For others such as Fedora the sources can be
> retrieved in a similar manner.
>
> The file can be added before the built starts and package so that the pd=
ump
> will contain the repository information and the VCS function will also
> work afterwards.
I don't fully understand how you can have a situation where you can get
this information in the Makefile, but you can't also get it when dumping
using `emacs-repository-get-version` and `emacs-repository-get-branch`
(lisp/loadup.el:474). Could you please elaborate on this?
Do you mean that you have one containerized process with Git that clones
emacs.git into a directory, and then an entirely separate containerized
process, without Git, builds Emacs from that very same directory? Or
something along those lines?
In this very particular scenario, isn't it enough to add this
additional step to your CI pipeline:
./src/emacs -Q --batch --eval '(princ (format "%s:%s" \
emacs-repository-version emacs-repository-branch))' > version.info
?
In other words, is it really necessary for us to support this use case
in our Makefile? Do we expect that building Emacs in such CI pipelines
using non-released development version of Emacs will be very common?
BTW, what is the name of that CI system that you're using here? For
what purpose are you building Emacs: to test Elisp packages, to test
Emacs, or something else? Finally, why are you not using officially
tagged versions, either from us or from some distro, in this context?
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.
Received: (at 74413) by debbugs.gnu.org; 18 Nov 2024 21:49:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 18 16:49:14 2024
Received: from localhost ([127.0.0.1]:39458 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tD9cP-0004Vw-OL
for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 16:49:14 -0500
Received: from thaodan.de ([185.216.177.71]:33638)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bjorn.bidar@HIDDEN>) id 1tD9cM-0004Vi-Pp
for 74413 <at> debbugs.gnu.org; Mon, 18 Nov 2024 16:49:12 -0500
Received: from odin (dsl-trebng12-50dc7b-49.dhcp.inet.fi [80.220.123.49])
by thaodan.de (Postfix) with ESMTPSA id 64F10D00071;
Mon, 18 Nov 2024 23:48:39 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail;
t=1731966519; bh=rCXiUEqBgfJ/S0nDf13BTJnHtwucxruaGkBr1TRZvvk=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=bPZDucgrheRYbFEntKKgoTNrOIl0Ae+3t9URfbSpzj96V/FPJjQZ37LP3q1d2ALNL
+coHDVJCe4JDS/CR9/oQiH3sg8A+96svvOULyzTJ4GfHlk+Wq3+1Ds5heEz50Ar1Nn
tBTxA2oKvhUrixL9HdL1zKIaKH/eT6mfdJsP6deNdi1TO112SVjv2dNvW2CLVArwuB
MpirkbF7xR9wdJVBlholQ3zEmO+tHKtFEa+SN0bF6FpmOIrsDpyWuK/5cEwq4CNuzK
CqG8JxAtcgFF55QFVqY4m85Tlo2QVADntdwfPLR2B+JQONauvc6zCdzN5a1APfRyhN
qTuhggdLCuFz8XETHIMrRBD5kxPKuZ9nYbPxmYtwClWQGTEA/JLfJNZ+FhhkWkXlvr
TVLV9wqI9Bwg5DBz5TWA0OSoYtnIqmrmmkMbFzylYqlXeXSJLKQgbiAz3dAPyHzSSG
SLqFqxEtOXth9b4Ypg0jKDxoZ1K/MzfG2S71yW7VWPt72UcRpCw5ZgSQHByCSTW7FE
r3aVPep4VhSr7Wj3TyCmF1MRUDC84vyuaS0YZnjjhDNh5AJeig8a7fNx3GP6x6yNDD
BJTbAFhsM6NThWUj6rHHkNsemiolbLv3lF2SotESFixpyEiVMMBLotg+XuLPPGVihm
q413h+haIrp+wFdbY4EHoqVE=
From: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#74413: [PATCH] Allow to store and read repository
information of VCS builds
In-Reply-To: <86zflwtjlz.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 18 Nov
2024 21:41:44 +0200")
References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN>
<861pz8uzyo.fsf@HIDDEN> <86zflwtjlz.fsf@HIDDEN>
Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq
w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV
CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl
HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8
phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF
CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h
K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2
cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC
HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN
XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg
gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL
AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E
TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB
B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe
pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO
HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG
AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr
dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n
KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy
GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK
S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA==
Date: Mon, 18 Nov 2024 23:48:38 +0200
Message-ID: <87y11g5i2x.fsf@>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii <eliz@HIDDEN> writes: >> From: Björn Bidar
<bjorn.bidar@HIDDEN> >> Cc: stefankangas@HIDDEN, luangruo@HIDDEN,
74413 <at> debbugs.gnu.org >> Date: Mon, 18 Nov 2024 21:31:43 +0200 >> >> Eli
Zaretskii <eliz@HIDDEN> writ [...]
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in bl.score.senderscore.com]
0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
The query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in sa-accredit.habeas.com]
1.2 INVALID_MSGID Message-Id is not valid, according to RFC 2822
X-Debbugs-Envelope-To: 74413
Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN>
>> Cc: stefankangas@HIDDEN, luangruo@HIDDEN, 74413 <at> debbugs.gnu.org
>> Date: Mon, 18 Nov 2024 21:31:43 +0200
>>=20
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>=20
>> >> From: Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN>
>> >> Cc: Stefan Kangas <stefankangas@HIDDEN>, luangruo@HIDDEN,
>> >> 74413 <at> debbugs.gnu.org
>> >> Date: Mon, 18 Nov 2024 18:54:26 +0200
>> >>=20
>> >> Eli Zaretskii <eliz@HIDDEN> writes:
>> >>=20
>> >> > This is already available if Emacs is built in a Git repository, and
>> >> > the information is stored in the dumped Emacs. So what is gained by
>> >> > also recording the repository version on a disk file external to
>> >> > Emacs?
>> >>=20
>> >> The information is only stored if the worker already had git installed
>> >> and checked out the sources with git inside the worker.
>> >> Also the function currently fails unless the system the user uses als=
o happens to
>> >> have git installed and the sources if the are installed also contain =
the
>> >> VCS metadata.
>> >> Storing the VCS metadata in the sources doesn't happen usually as it
>> >> increases the size of a good chunk. In my case e.g. from 188MB to 788=
MB.
>> >> Why not have the same feature for other platforms too?
>> >
>> > Sorry, I don't understand this explanation; I'm probably missing
>> > something.
>> >
>> > The feature you propose requires to build Emacs inside a Git
>> > repository, is that correct? Because otherwise "git rev-parse" will
>> > not work, right? If that is correct, then building Emacs inside a Git
>> > repository already calls this Git command and records the result in 2
>> > Emacs Lisp variables.
>> >
>> > So why do you also want to record the same
>> > information on a file? What kind of scenario do you have in mind in
>> > which building Emacs with its current code will not record the branch
>> > and the revision, but your additions to Makefile will record that?
>>=20
>> The additions to the make file are so that if the worker contains git
>> the file can be generated so that the related functions will still work
>> after the built or to generate them prior the built. The latter probably
>> makes less sense except to maybe avoid having autotools in the built
>> dependency chain.
>>=20
>> If the Make recipe isn't used to generate the version file it can be
>> generated by the CI, e.g. in my case I take the information from the
>> open build source service. For others such as Fedora the sources can be
>> retrieved in a similar manner.
>>=20
>> The file can be added before the built starts and package so that the p=
dump
>> will contain the repository information and the VCS function will also
>> work afterwards.=20
>
> I still don't think I understand, sorry. Do you mean the file is
> generated from a Git repository, but then Emacs is somehow built from
> a directory that is not under Git?
The file can be generated from the git repository outside of the Emacs
builder.
E.g. in my case the obs source service store's the git revision used in
the service=20
In my case the file looks like this:
name: emacs
version: 31.0.50.9794.eee0ed8442a
mtime: 1731883844
commit: eee0ed8442aa78320a3e578ab290df145fb49624
sed -n -e 's/^commit: \(.*\)/\1/p' emacs.obsinfo > etc/version
> But if this is the scenario, how can you be sure the produced Emacs binar=
y was made from that revision
> on that branch? This is only guaranteed if you actually build from
> Git when you record this information.
>
> What am I missing?
If the source is generated by the CI it can also store this information
in the build source which then can be extracted from the ci metadata to
the Emacs sources on the builder.
I can be sure that Emacs was built from that revision as much as I can
trust the CI to use the sources I told it to use. If I can't trust one,
I can't trust the other.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Received: (at 74413) by debbugs.gnu.org; 18 Nov 2024 19:41:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 18 14:41:58 2024 Received: from localhost ([127.0.0.1]:35229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tD7dF-0003Hj-MB for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 14:41:58 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tD7dD-0003HW-3h for 74413 <at> debbugs.gnu.org; Mon, 18 Nov 2024 14:41:56 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1tD7d7-0003YK-5j; Mon, 18 Nov 2024 14:41:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=pBHTa+DDQ0WFiRqJRXfo3KtKa7hhXyMxDOejFXidClU=; b=EMVYqNZ+1DYZIdtcN14w RZigi2YqiRJ0PqlPnMtogdFA0x68GS4lNKC6E0x+nxyqz/vj4F44LCU2O6bJb+ZFhqDQF63V3mbJL YSL4Vf5dXFxMvxmUpcbpd6e9hkD6Yza7rVGOiXEUkJAjUSIg+qCntP5iYKx06b71NGESwaPX0eOKA SWYtOAXNRJ35Vg6toZPS/k416+lpoYU/R5npyMZsZXso9yi0DhtPOMXUO7uw5+b0F01dSaNgjpJlq ZGHx5FNgbOkp9zBOxI+RBgO8vFvugu2ZEqErJFu5YfMR7HXhsQl/myPczcB/aptcTSUOyojLAEFFA vJthTj6ieLP5EQ==; Date: Mon, 18 Nov 2024 21:41:44 +0200 Message-Id: <86zflwtjlz.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN> In-Reply-To: <874j44wd7k.fsf@> (message from =?utf-8?Q?Bj=C3=B6rn?= Bidar on Mon, 18 Nov 2024 21:31:43 +0200) Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <861pz8uzyo.fsf@HIDDEN> <874j44wd7k.fsf@> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Bidar <bjorn.bidar@HIDDEN> > Cc: stefankangas@HIDDEN, luangruo@HIDDEN, 74413 <at> debbugs.gnu.org > Date: Mon, 18 Nov 2024 21:31:43 +0200 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> From: Björn Bidar <bjorn.bidar@HIDDEN> > >> Cc: Stefan Kangas <stefankangas@HIDDEN>, luangruo@HIDDEN, > >> 74413 <at> debbugs.gnu.org > >> Date: Mon, 18 Nov 2024 18:54:26 +0200 > >> > >> Eli Zaretskii <eliz@HIDDEN> writes: > >> > >> > This is already available if Emacs is built in a Git repository, and > >> > the information is stored in the dumped Emacs. So what is gained by > >> > also recording the repository version on a disk file external to > >> > Emacs? > >> > >> The information is only stored if the worker already had git installed > >> and checked out the sources with git inside the worker. > >> Also the function currently fails unless the system the user uses also happens to > >> have git installed and the sources if the are installed also contain the > >> VCS metadata. > >> Storing the VCS metadata in the sources doesn't happen usually as it > >> increases the size of a good chunk. In my case e.g. from 188MB to 788MB. > >> Why not have the same feature for other platforms too? > > > > Sorry, I don't understand this explanation; I'm probably missing > > something. > > > > The feature you propose requires to build Emacs inside a Git > > repository, is that correct? Because otherwise "git rev-parse" will > > not work, right? If that is correct, then building Emacs inside a Git > > repository already calls this Git command and records the result in 2 > > Emacs Lisp variables. > > > > So why do you also want to record the same > > information on a file? What kind of scenario do you have in mind in > > which building Emacs with its current code will not record the branch > > and the revision, but your additions to Makefile will record that? > > The additions to the make file are so that if the worker contains git > the file can be generated so that the related functions will still work > after the built or to generate them prior the built. The latter probably > makes less sense except to maybe avoid having autotools in the built > dependency chain. > > If the Make recipe isn't used to generate the version file it can be > generated by the CI, e.g. in my case I take the information from the > open build source service. For others such as Fedora the sources can be > retrieved in a similar manner. > > The file can be added before the built starts and package so that the pdump > will contain the repository information and the VCS function will also > work afterwards. I still don't think I understand, sorry. Do you mean the file is generated from a Git repository, but then Emacs is somehow built from a directory that is not under Git? But if this is the scenario, how can you be sure the produced Emacs binary was made from that revision on that branch? This is only guaranteed if you actually build from Git when you record this information. What am I missing?
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.
Received: (at 74413) by debbugs.gnu.org; 18 Nov 2024 19:31:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 18 14:31:49 2024
Received: from localhost ([127.0.0.1]:35217 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tD7TR-0002pt-EU
for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 14:31:49 -0500
Received: from thaodan.de ([185.216.177.71]:37142)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bjorn.bidar@HIDDEN>) id 1tD7TO-0002pi-SU
for 74413 <at> debbugs.gnu.org; Mon, 18 Nov 2024 14:31:48 -0500
Received: from odin (dsl-trebng12-50dc7b-49.dhcp.inet.fi [80.220.123.49])
by thaodan.de (Postfix) with ESMTPSA id 41035D00071;
Mon, 18 Nov 2024 21:31:45 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail;
t=1731958305; bh=T2Mp3lxzCG89MgnvduMwdUgLHQ9BVogYFxGPZZkZSLA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=ePQ9n8NRfULMREpvM+UdLUnSBgt+O0etPZ6KeysWosGDOohWqunbH4eeKtv3Dcu8t
/d/OUn3+PRYtMFUEY/seA742s2JK53oYvZGuEmDoEEFruDiX+7rUK/q8gaLI3/7Kw5
faOoH7sz5XZ2DJcTdwAAO9pmh5C3lYOMQ9GFgn1Nxg67vb9/gc5X20ITxfBU5qRjl1
amhzIJuuC6hRI80+AQfwt2sP1Hq8ow/P2r3RrInzKhUtWOh1biJiKiS6bquERh/4q8
mZ0oLzPPSk/cyF0SIoa2ztQtSV9oeT4jZZ3V/TLV1W3f6qi2yfwcmzM65NQLMQ10Bg
ywaWZofGjwRs/UA6x6VbWu3AnEZrmATsrS7u2wWEUlipqsKMjprZM/7UeI+vVyxu+I
1xW9IU+M/otH37GsYiNf9S6ZV8dPvZI+oNXpbkJ6+oYosb55K7lmv/lrMHidV/pyaU
pmqtxV8P5nbzddwH+EwfP1RfGBxnSGFRJVZZC6GRgY3pCI1imv+69vuT4UV9EXBW1e
3k/bWhaZEg82+TYByktP9V0MOR7RwkCYjB5EYt9u44kJsVyIcqUi9bGN6WcDITD9Jr
r1wjGjChIZmHxID85L6qX36M/j/IOqMv+vBdwl2HZrjyde76IsWowO+ckpb+NucTJH
rWmZ9kcL7ftkEIwF0L2X0w/w=
From: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#74413: [PATCH] Allow to store and read repository
information of VCS builds
In-Reply-To: <861pz8uzyo.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 18 Nov
2024 21:03:11 +0200")
References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN>
<861pz8uzyo.fsf@HIDDEN>
Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq
w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV
CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl
HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8
phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF
CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h
K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2
cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC
HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN
XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg
gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL
AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E
TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB
B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe
pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO
HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG
AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr
dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n
KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy
GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK
S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA==
Date: Mon, 18 Nov 2024 21:31:43 +0200
Message-ID: <874j44wd7k.fsf@>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii <eliz@HIDDEN> writes: >> From: Björn Bidar
<bjorn.bidar@HIDDEN> >> Cc: Stefan Kangas <stefankangas@HIDDEN>, luangruo@HIDDEN,
>> 74413 <at> debbugs.gnu.org >> Date: Mon, 18 Nov 2024 18:54:26 +0200 >> >> Eli
Zaretskii [...]
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
The query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in sa-trusted.bondedsender.org]
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in bl.score.senderscore.com]
1.2 INVALID_MSGID Message-Id is not valid, according to RFC 2822
X-Debbugs-Envelope-To: 74413
Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, stefankangas@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN>
>> Cc: Stefan Kangas <stefankangas@HIDDEN>, luangruo@HIDDEN,
>> 74413 <at> debbugs.gnu.org
>> Date: Mon, 18 Nov 2024 18:54:26 +0200
>>=20
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>=20
>> > This is already available if Emacs is built in a Git repository, and
>> > the information is stored in the dumped Emacs. So what is gained by
>> > also recording the repository version on a disk file external to
>> > Emacs?
>>=20
>> The information is only stored if the worker already had git installed
>> and checked out the sources with git inside the worker.
>> Also the function currently fails unless the system the user uses also h=
appens to
>> have git installed and the sources if the are installed also contain the
>> VCS metadata.
>> Storing the VCS metadata in the sources doesn't happen usually as it
>> increases the size of a good chunk. In my case e.g. from 188MB to 788MB.
>> Why not have the same feature for other platforms too?
>
> Sorry, I don't understand this explanation; I'm probably missing
> something.
>
> The feature you propose requires to build Emacs inside a Git
> repository, is that correct? Because otherwise "git rev-parse" will
> not work, right? If that is correct, then building Emacs inside a Git
> repository already calls this Git command and records the result in 2
> Emacs Lisp variables.
>
> So why do you also want to record the same
> information on a file? What kind of scenario do you have in mind in
> which building Emacs with its current code will not record the branch
> and the revision, but your additions to Makefile will record that?
The additions to the make file are so that if the worker contains git
the file can be generated so that the related functions will still work
after the built or to generate them prior the built. The latter probably
makes less sense except to maybe avoid having autotools in the built
dependency chain.
If the Make recipe isn't used to generate the version file it can be
generated by the CI, e.g. in my case I take the information from the
open build source service. For others such as Fedora the sources can be
retrieved in a similar manner.
The file can be added before the built starts and package so that the pdump
will contain the repository information and the VCS function will also
work afterwards.=20
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Received: (at 74413) by debbugs.gnu.org; 18 Nov 2024 19:03:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 18 14:03:25 2024 Received: from localhost ([127.0.0.1]:35169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tD71w-0001Tu-QM for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 14:03:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57678) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tD71t-0001Tc-Sz for 74413 <at> debbugs.gnu.org; Mon, 18 Nov 2024 14:03:22 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1tD71n-0006zx-SY; Mon, 18 Nov 2024 14:03:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=p650dfUq6XslKIhYENY3Uxqw7p4cbI0ExEIMcjLy3Wg=; b=NJ3t1y2LfoqYdYZeOiQ3 Huym1nL4ZhffTCP1C/DgrKgEOgjGB3kCujZ21IgawqWEKiORbjr9VlfhjThj9xTVvz6tvvvZ6+ZnD oRUnhYQPEzBvWMsxxt0CDw7QPzfzd1JOpw1G7+ZAxC7RlqD5ze5FIsOcXOQewPSTahPLr3MVps4xi RpyBqT8RwR5ByyNOWGCSNiVVi0YwZulXW7wHVzm65od9zPxbd3II1V1u5t3HCwYmWsJrKXTbLLWxk sl6pEb9/rSxnwY9zlJXK7qAVcjzIigEty5M1O79AXsTP+R9+Z9pr1KmHCAKQXlXYyyBVi8tBhxIio OLEa6BJO/NjnUA==; Date: Mon, 18 Nov 2024 21:03:11 +0200 Message-Id: <861pz8uzyo.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN> In-Reply-To: <87frnowkhp.fsf@> (message from =?utf-8?Q?Bj=C3=B6rn?= Bidar on Mon, 18 Nov 2024 18:54:26 +0200) Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN> <87frnowkhp.fsf@> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Bidar <bjorn.bidar@HIDDEN> > Cc: Stefan Kangas <stefankangas@HIDDEN>, luangruo@HIDDEN, > 74413 <at> debbugs.gnu.org > Date: Mon, 18 Nov 2024 18:54:26 +0200 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > This is already available if Emacs is built in a Git repository, and > > the information is stored in the dumped Emacs. So what is gained by > > also recording the repository version on a disk file external to > > Emacs? > > The information is only stored if the worker already had git installed > and checked out the sources with git inside the worker. > Also the function currently fails unless the system the user uses also happens to > have git installed and the sources if the are installed also contain the > VCS metadata. > Storing the VCS metadata in the sources doesn't happen usually as it > increases the size of a good chunk. In my case e.g. from 188MB to 788MB. > Why not have the same feature for other platforms too? Sorry, I don't understand this explanation; I'm probably missing something. The feature you propose requires to build Emacs inside a Git repository, is that correct? Because otherwise "git rev-parse" will not work, right? If that is correct, then building Emacs inside a Git repository already calls this Git command and records the result in 2 Emacs Lisp variables. So why do you also want to record the same information on a file? What kind of scenario do you have in mind in which building Emacs with its current code will not record the branch and the revision, but your additions to Makefile will record that?
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.
Received: (at 74413) by debbugs.gnu.org; 18 Nov 2024 16:54:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 18 11:54:34 2024
Received: from localhost ([127.0.0.1]:34975 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tD51G-00041D-2f
for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 11:54:34 -0500
Received: from thaodan.de ([185.216.177.71]:42340)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bjorn.bidar@HIDDEN>) id 1tD51D-000410-6a
for 74413 <at> debbugs.gnu.org; Mon, 18 Nov 2024 11:54:32 -0500
Received: from odin (dsl-trebng12-50dc7b-49.dhcp.inet.fi [80.220.123.49])
by thaodan.de (Postfix) with ESMTPSA id 3A96AD00083;
Mon, 18 Nov 2024 18:54:28 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail;
t=1731948868; bh=uhRkR9ej8gbZG6vXZ2U+zF39tjkMT0U7xBLs4L4LBLY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=ZlQsjmRZsSy2+YIFKA8kqZ3NpoNn3ofO1OWqBs+FOqBdEVzm95qPtP/uQBQMGGMza
59nocjvjlqvY1Ooy/TdH6P7U7Efy2dcba5KpQDneK1IvuZjM3701bJYKm9/b6PcbW/
ZJ+Ci+lYKmLj6bjvmbvkUDf4dZHvsi2cpYMXnnlotpgSm227mqeg1QLyNUvxBRt7c6
9js49ikz5PRqMXWjnpXM2Fk/MPvDsNmYaFVFu1WvHJlR1wfDhBzft50xfTCaXovK1c
I5HrXDM2q60OJyITM+wDH8o1YKKB6gkEn64h4s4BBR2O7L+3VYw6+yuKxLn+9vhySS
XSmVUTsbPR06CmhswmKuH3tGWneEqmT8QMQQ0HXRyYSsxzLUOFWma09/P1esd3B5Pr
WyNPqN3iCTsFJdjWlHBJ/V/tXHXDHGVgS3BGctjgwEsi2bD5wTsgmggEsK62pagjnV
lNV6dFfpm+w23i9ufPAqTv0MLtQCQK6uLQBi9ayMNjmwapySZj8PSf1TitcUer0vAa
H7yFd88LujGXiMxah+AJomKlRHYhTlCTNa8GudQXH/s/Pi6uNXTR1+6jZrmzGV/GV9
RW1tOm+qu13jnNEQhGIr2pSI3lrXdTtrEwjVj8LXJScE4aoSzUl+Df3xhWGP6eO6vE
FcputJH8944yxBw3ZVT6vD5E=
From: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#74413: [PATCH] Allow to store and read repository
information of VCS builds
In-Reply-To: <867c90vbfk.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 18 Nov
2024 16:55:27 +0200")
References: <86frnovhg8.fsf@HIDDEN> <867c90vbfk.fsf@HIDDEN>
Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq
w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV
CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl
HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8
phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF
CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h
K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2
cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC
HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN
XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg
gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL
AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E
TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB
B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe
pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO
HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG
AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr
dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n
KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy
GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK
S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA==
Date: Mon, 18 Nov 2024 18:54:26 +0200
Message-ID: <87frnowkhp.fsf@>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii <eliz@HIDDEN> writes: >> From: Björn Bidar
<bjorn.bidar@HIDDEN> >> Cc: Po Lu <luangruo@HIDDEN>, 74413 <at> debbugs.gnu.org
>> Date: Mon, 18 Nov 2024 16:21:28 +0200 >> >> > Doesn't that go against
the tendency to have _l [...]
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
The query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in sa-trusted.bondedsender.org]
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in bl.score.senderscore.com]
1.2 INVALID_MSGID Message-Id is not valid, according to RFC 2822
X-Debbugs-Envelope-To: 74413
Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org,
Stefan Kangas <stefankangas@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN>
>> Cc: Po Lu <luangruo@HIDDEN>, 74413 <at> debbugs.gnu.org
>> Date: Mon, 18 Nov 2024 16:21:28 +0200
>>=20
>> > Doesn't that go against the tendency to have _less_ detailed/private
>> > information in the build? We've lately removed some relatively useful
>> > infos from what we report in commands that use the build information.
>>=20
>> The information added is only the branch and the repository similarly as
>> used by the Android builds. There's no private information there unless
>> the exact change reference Emacs was built on is private.
>
> The branch name could be private.
That could be but at that point you wouldn't have access to the binary
that contains the information and probably wouldn't report bugs to this
tracker either I think.
> Stefan, WDYT about this feature suggestion?
>
>> > More generally, could you present the motivation and the rationale for
>> > making this information available in production builds?
>>=20
>> The information wouldn't be only available to production builds but also
>> testing/developer builds that are builtin in a CI environment to
>> e.g. provide test builds for developers to use or to instruct user to
>> use to try to reproduce a bug.
>>=20
>> Even for production builds it could be useful for convenience to track
>> down the exact reference/branch a build came from from, that's
>> side effect only thou.
>
> This is already available if Emacs is built in a Git repository, and
> the information is stored in the dumped Emacs. So what is gained by
> also recording the repository version on a disk file external to
> Emacs?
The information is only stored if the worker already had git installed
and checked out the sources with git inside the worker.
Also the function currently fails unless the system the user uses also happ=
ens to
have git installed and the sources if the are installed also contain the
VCS metadata.
Storing the VCS metadata in the sources doesn't happen usually as it
increases the size of a good chunk. In my case e.g. from 188MB to 788MB.
Why not have the same feature for other platforms too?
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.Received: (at 74413) by debbugs.gnu.org; 18 Nov 2024 14:58:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 18 09:58:18 2024 Received: from localhost ([127.0.0.1]:34731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tD3Ck-0006qg-Al for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 09:58:18 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tD3Ci-0006qT-9p for 74413 <at> debbugs.gnu.org; Mon, 18 Nov 2024 09:58:16 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1tD3AV-0008AH-BJ; Mon, 18 Nov 2024 09:55:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=ZXZycM0BBoqoYl+QU4Xmo/fgpVfgD5GQNusGSCz1AhU=; b=lZdME8ni+cgK4L7XQRgQ ngrmG4vlVbThJdVd2udwN0L7kKvJhg9BLFpjsw4gWoV7TI8uOIRvpA99GeX2xL4VrUrcU17qPNvOR PHVuwndBFEC4vE40TtkUUkEEru9tXcuw1ZdXcHtk82taVNLcfDi8o/CM3Sm7byjN7Fi0VAzyKv3JT LVtI/hD1UWy7/VyJQmE0xfSKq/cN12BH+m4Gt1FlBQ69uUh7rnIs1znC/1IkElC1OSx/U19BGJcmv ywgnyEgfjvN0/cLHXrixt1QL2WmZfDJJsDjeS9i4nakwQVpfpgUd73z1RZ9b8H8ccyr4A23/kWjVq fQ/6CvtmvDDA+A==; Date: Mon, 18 Nov 2024 16:55:27 +0200 Message-Id: <867c90vbfk.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <875xoklj13.fsf@> (message from =?utf-8?Q?Bj=C3=B6rn?= Bidar on Mon, 18 Nov 2024 16:21:28 +0200) Subject: Re: bug#74413: [PATCH] Allow to store and read repository information of VCS builds References: <86frnovhg8.fsf@HIDDEN> <875xoklj13.fsf@> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74413 Cc: luangruo@HIDDEN, 74413 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Björn Bidar <bjorn.bidar@HIDDEN> > Cc: Po Lu <luangruo@HIDDEN>, 74413 <at> debbugs.gnu.org > Date: Mon, 18 Nov 2024 16:21:28 +0200 > > > Doesn't that go against the tendency to have _less_ detailed/private > > information in the build? We've lately removed some relatively useful > > infos from what we report in commands that use the build information. > > The information added is only the branch and the repository similarly as > used by the Android builds. There's no private information there unless > the exact change reference Emacs was built on is private. The branch name could be private. Stefan, WDYT about this feature suggestion? > > More generally, could you present the motivation and the rationale for > > making this information available in production builds? > > The information wouldn't be only available to production builds but also > testing/developer builds that are builtin in a CI environment to > e.g. provide test builds for developers to use or to instruct user to > use to try to reproduce a bug. > > Even for production builds it could be useful for convenience to track > down the exact reference/branch a build came from from, that's > side effect only thou. This is already available if Emacs is built in a Git repository, and the information is stored in the dumped Emacs. So what is gained by also recording the repository version on a disk file external to Emacs?
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.
Received: (at 74413) by debbugs.gnu.org; 18 Nov 2024 14:22:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 18 09:22:02 2024
Received: from localhost ([127.0.0.1]:60685 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tD2dd-0004Ya-Hr
for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 09:22:02 -0500
Received: from thaodan.de ([185.216.177.71]:57660)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bjorn.bidar@HIDDEN>) id 1tD2db-0004YN-SH
for 74413 <at> debbugs.gnu.org; Mon, 18 Nov 2024 09:22:00 -0500
Received: from odin (dsl-trebng12-50dc7b-49.dhcp.inet.fi [80.220.123.49])
by thaodan.de (Postfix) with ESMTPSA id A392ED0008E;
Mon, 18 Nov 2024 16:21:28 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail;
t=1731939688; bh=o8kAOZrLR6Jx0472X32+glrUgAH+zgUTiWapCl7+Brg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=jsUJC4LvNwKfAXhYnNMCHb2RBMzfHE65dRIppnLKHlQ0lr+Y2LnOfc/h3z3trcBDE
ccp3+sOzRBb7sig5J/FhUPS/PnMAKEXUG3t/NfXUtegLDp0E12jWMFouMpfIcUi14B
qM46hiyv1QruV3tdAZnc77FLbKnGkJ3ZdWHwARO8t6q4RseR7rCaX9gMpPuiSUuDIs
cT2H/vfNbAL5mhI2PWf54sep3UfT/sAlXZpNJ6JOy0MYtv3O6mYfkz8Tv+vgE4jA9z
EvK+LBwVIQHayTEueb8dOr5x7AjjAiQ86AsRkDDRjWP9Oe7vhjggT5Z1zt+T3++Mpl
m3WTXUyAkaGSr4Bojp7fh01lhZT0A3Sf82kXuvnSoYsxN3hvhwDPejzzNniSHV3X51
IUrV+fYmDVqqUKAbhSq9Csjm4s+vt6HKezHq7eMGOi0Zp6zbnZdv3Izr1evfcbDFiJ
cfnHLzQkEFvqw15nYTKfqonriCAJkUeAmevniY3w2neFy32QuP8ibXOSfsqVBoLfWr
fXD4NUXXC1EiDsHAT7xRSzuXWw+P0CyZmiLCSROS13R6Qar74GGoTw2l6KdRZpqyyv
T5NxgX1LdbKm26jcMsN3oJfrX1IAFr/7UJmfmnZ7EMIyc0LPbOsDqvvidAAjXjwubN
MYY0RbM9iSNyjfCzIkWpuhrE=
From: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#74413: [PATCH] Allow to store and read repository
information of VCS builds
In-Reply-To: <86frnovhg8.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 18 Nov
2024 14:45:27 +0200")
References: <86frnovhg8.fsf@HIDDEN>
Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq
w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV
CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl
HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8
phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF
CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h
K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2
cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC
HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN
XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg
gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL
AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E
TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB
B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe
pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO
HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG
AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr
dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n
KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy
GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK
S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA==
Date: Mon, 18 Nov 2024 16:21:28 +0200
Message-ID: <875xoklj13.fsf@>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii <eliz@HIDDEN> writes: >> Date: Mon, 18 Nov
2024 10:18:11 +0200 >> From: Björn Bidar via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> Emacs
has the feature to read the [...]
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
The query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in sa-trusted.bondedsender.org]
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.216.177.71 listed in bl.score.senderscore.com]
1.2 INVALID_MSGID Message-Id is not valid, according to RFC 2822
X-Debbugs-Envelope-To: 74413
Cc: Po Lu <luangruo@HIDDEN>, 74413 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Eli Zaretskii <eliz@HIDDEN> writes:
>> Date: Mon, 18 Nov 2024 10:18:11 +0200
>> From: Bj=C3=B6rn Bidar via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>=20
>> Emacs has the feature to read the repository version and
>> branch if git is installed during the build and afterwards if also
>> the sources including the VCS repository is present.
>>=20
>> For the Android builds the feature was added to store and read the
>> information mentioned above in a special version file.
>
> Po Lu, why is that needed in the Android build, and how is it used
> there?
>
>> This patch reuses that mechanism so it can be reused on other platforms
>> to use for the same reasons its available for Android and to also be
>> able to use the information on CI workers without git installed and/or a
>> full source checkout.
>
> Doesn't that go against the tendency to have _less_ detailed/private
> information in the build? We've lately removed some relatively useful
> infos from what we report in commands that use the build information.
The information added is only the branch and the repository similarly as
used by the Android builds. There's no private information there unless
the exact change reference Emacs was built on is private.
> More generally, could you present the motivation and the rationale for
> making this information available in production builds?
The information wouldn't be only available to production builds but also
testing/developer builds that are builtin in a CI environment to
e.g. provide test builds for developers to use or to instruct user to
use to try to reproduce a bug.
Even for production builds it could be useful for convenience to track
down the exact reference/branch a build came from from, that's
side effect only thou.
>> The things I'm not sure about for this patch are:
>> - Is the generating of the version file in the right place in
>> Makefile.in
>
> It should be in the build tree, yes.
I was more talking if the section for the file should be in a separate
recipe or if etc-emacsver fits this purpose, I think the usecase is
quite close so it does sound ok to me.
>> - Is the data directory the right place to store the file
>
> Not sure, but I don't see why not.
OK I was just mostly wondering about the macOS builds who don't ship the
etc dir but since the information is be present also during dumping if
so desired it shouldn't be a big issue anyway.
>> - Should the creation of the version file be shared between the Android
>> builds and the other platforms
>
> Let's first discuss whether this is at all needed and a good idea,
> okay?
Sure np, I was mostly speaking out load.
>
>> - ${INSTALL_PROGRAM} $(INSTALL_STRIP) src/emacs${EXEEXT} "$(DESTDIR)${bi=
ndir}/$(EMACSFULL)"
>> + ${INSTALL_PROGRAM} $(INSTALL_STRIP) src/emacs${EXEEXT} "$(DESTDIR)${bi=
ndir}/$(EMACS)"
>
> Why this change (and other similar ones)? What does EMACSFULL have to
> do with the repository version data?
>
>> @@ -826,6 +837,7 @@ install-man:
>> umask 022; ${MKDIR_P} "$(DESTDIR)${man1dir}"
>> thisdir=3D`pwd -P`; \
>> cd ${mansrcdir}; \
>> + cp ctags.1 gnuctags.1; \
>
> This hunk also looks unrelated.
I'm sorry these changes came in accidentally. I attached a fixed patch belo=
w:
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Allow-to-store-and-read-repository-information-of-VC.patch
From d522173a61a84237d098690ee5289d2c11307306 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Bidar?= <bjorn.bidar@HIDDEN>
Date: Mon, 18 Nov 2024 16:18:40 +0200
Subject: [PATCH] Allow to store and read repository information of VCS builds
Store repository information in version file if Emacs is build from
source while VCS is present. The version file can also be stored in the Emacs
sources prior built to indicate if Emacs was built from VCS sources.
An example use case could be if Emacs runs on a system where
the version control system isn't available, e.g. similarly
as it is intended for Android builds.
Another one is to be able to set the VCS information for workers
in a CI environment where sources are generated separately from VCS
but it or the VCS repository isn't present on the worker.
Reuse the same mechanism that exist for Android builds if the version
file is present.
* Makefile.in (etc-emacsver):
Generate etc/version file with revision and branch if git is installed
and Emacs sources are VCS sources.
* lisp/version.el (emacs-repository-get-branch)
(emacs-repository-get-version, emacs-repository-branch-static)
(emacs-repository-version-static):
Implement static versions that can use the information generated during
build if present.
---
.gitignore | 1 +
Makefile.in | 13 ++++++++++++-
lisp/version.el | 44 ++++++++++++++++++++++++++++++++------------
3 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/.gitignore b/.gitignore
index c1f31514d06..d3b737d590c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -314,6 +314,7 @@ doc/misc/modus-themes.texi
doc/misc/org.texi
etc/DOC
etc/refcards/emacsver.tex
+etc/version
gnustmp*
/info/
diff --git a/Makefile.in b/Makefile.in
index 30a762ed03b..2817742af86 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -452,7 +452,18 @@ etc-emacsver:
sed "s/[@]majorversion@/$${majorversion}/" \
${srcdir}/etc/refcards/emacsver.tex.in > emacsver.tex.$$$$ && \
${srcdir}/build-aux/move-if-change emacsver.tex.$$$$ \
- ${srcdir}/etc/refcards/emacsver.tex
+ ${srcdir}/etc/refcards/emacsver.tex; \
+ if [ -e $(srcdir)/.git ] && \
+ which git > /dev/null ; then \
+ { (cd $(srcdir) \
+ && git rev-parse HEAD || echo "Unknown") \
+ && (git rev-parse --abbrev-ref HEAD \
+ || echo "Unknown") } 2> /dev/null > \
+ ${top_builddir}/etc/version.$$$$; \
+ ${srcdir}/build-aux/move-if-change \
+ ${top_builddir}/etc/version.$$$$ \
+ ${top_builddir}/etc/version; \
+ else : ;fi
# The shared gamedir name as a C string literal, or a null ptr if not in use.
PATH_GAME = $(if $(use_gamedir),"$(gamedir)",((char const *) 0))
diff --git a/lisp/version.el b/lisp/version.el
index db2afd55694..3b2c91c03dc 100644
--- a/lisp/version.el
+++ b/lisp/version.el
@@ -171,15 +171,21 @@ emacs-repository-version-git
(looking-at "[[:xdigit:]]\\{40\\}"))
(match-string 0)))))
-(defun emacs-repository-version-android ()
+(defun emacs-repository-version-static (dir)
"Return the Emacs repository revision Emacs was built from.
Value is nil if Emacs was not built from a repository checkout.
-Use information from the `/assets/version' special file."
+Use information from the `DIR/version' special file."
(with-temp-buffer
- (insert-file-contents "/assets/version")
+ (insert-file-contents (expand-file-name "version" dir))
(let ((string (buffer-substring 1 (line-end-position))))
(and (not (equal string "Unknown")) string))))
+(defun emacs-repository-version-android ()
+ "Return the Emacs repository revision Emacs was built from.
+Value is nil if Emacs was not built from a repository checkout.
+Use information from the `/assets/version' special file."
+ (emacs-repository-version-static "/assets"))
+
(defun emacs-repository-get-version (&optional dir _external)
"Try to return as a string the repository revision of the Emacs sources.
The format of the returned string is dependent on the VCS in use.
@@ -194,9 +200,13 @@ emacs-repository-get-version
Optional argument DIR is a directory to use instead of `source-directory'.
Optional argument EXTERNAL is ignored."
- (cond ((and (featurep 'android)
- (eq system-type 'android))
- (emacs-repository-version-android))
+ (cond ((and (or (and (featurep 'android)
+ (eq system-type 'android)
+ (setq dir "/assets"))
+ (and (not dir)
+ (file-exists-p (expand-file-name "version" data-directory))
+ (setq dir data-directory)))
+ (emacs-repository-version-static dir)))
(t (emacs-repository-version-git
(or dir source-directory)))))
@@ -209,8 +219,14 @@ emacs-repository-branch-android
"Return the Emacs repository branch Emacs was built from.
Value is nil if Emacs was not built from a repository checkout.
Use information from the `/assets/version' special file."
+ (emacs-repository-branch-static "/assets"))
+
+(defun emacs-repository-branch-static (dir)
+ "Return the Emacs repository branch Emacs was built from.
+Value is nil if Emacs was not built from a repository checkout.
+Use information from the `DIR/version' special file."
(with-temp-buffer
- (insert-file-contents "/assets/version")
+ (insert-file-contents (expand-file-name "version" dir))
(end-of-line)
(forward-char)
(let ((string (buffer-substring (point) (line-end-position))))
@@ -232,8 +248,8 @@ emacs-repository-get-branch
"Try to return as a string the repository branch of the Emacs sources.
The format of the returned string is dependent on the VCS in use.
-If Emacs is built for Android, use the version information
-embedded in the Emacs installation package.
+If Emacs is built for Android or contains version file,
+use the version information embedded in the Emacs installation package.
Value is nil if the sources do not seem to be under version
control, or if we could not determine the branch. Note that
@@ -241,9 +257,13 @@ emacs-repository-get-branch
correspond to the running Emacs.
Optional argument DIR is a directory to use instead of `source-directory'."
- (cond ((and (featurep 'android)
- (eq system-type 'android))
- (emacs-repository-branch-android))
+ (cond ((and (or (and (featurep 'android)
+ (eq system-type 'android)
+ (setq dir "/assets"))
+ (and (not dir)
+ (file-exists-p (expand-file-name "version" data-directory))
+ (setq dir data-directory)))
+ (emacs-repository-branch-static dir)))
(t (emacs-repository-branch-git
(or dir source-directory)))))
--
2.45.2
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.
Received: (at 74413) by debbugs.gnu.org; 18 Nov 2024 12:45:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 18 07:45:39 2024
Received: from localhost ([127.0.0.1]:60444 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tD18N-0008To-G9
for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 07:45:39 -0500
Received: from eggs.gnu.org ([209.51.188.92]:32898)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1tD18L-0008Tb-O7
for 74413 <at> debbugs.gnu.org; Mon, 18 Nov 2024 07:45:38 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1tD18F-0005JJ-Jh; Mon, 18 Nov 2024 07:45:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=qf1uKMQOTqFV9KJfKuZrb/y6IT3RU/uJBswGC1HCSks=; b=DZ+CqsTXRa3Q35EiZaSX
rxqLkAFFQACKcmN9ZPNw4S0D/+1R/JSIB1OouhHY4io+G3qtAJS+xwSxRrZBGkibJ8iukzIzpF0Ok
fZIV2gxRqynwMy/Ia4nsKhKyf4+VWaDe+HlxpxckMph3OYjH+TgoQTnX1dTKnuvAoNQIJwJ+VFkL/
7LwijWnokgDQnDjXUCxngcTNbV8nyZPvStQ8QlTuZinNmvS5PT9jy8KsVuqGYqrWmNYcQ9ko/3xKU
WvctS2mxRwYTg+3E6B4rr2SOh5XfLRl1/wsIBT8syFLgmTucCJ2v4l6jt9TlEdr/8X9KsGx/2Bmt7
TSn3kbig0hIOlw==;
Date: Mon, 18 Nov 2024 14:45:27 +0200
Message-Id: <86frnovhg8.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: =?iso-8859-1?Q?Bj=F6rn?= Bidar <bjorn.bidar@HIDDEN>, Po Lu
<luangruo@HIDDEN>
In-Reply-To: <87wmh1j6po.fsf@> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#74413: [PATCH] Allow to store and read repository information
of VCS builds
References: <87wmh1j6po.fsf@>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 74413
Cc: 74413 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Mon, 18 Nov 2024 10:18:11 +0200
> From: Björn Bidar via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
> Emacs has the feature to read the repository version and
> branch if git is installed during the build and afterwards if also
> the sources including the VCS repository is present.
>
> For the Android builds the feature was added to store and read the
> information mentioned above in a special version file.
Po Lu, why is that needed in the Android build, and how is it used
there?
> This patch reuses that mechanism so it can be reused on other platforms
> to use for the same reasons its available for Android and to also be
> able to use the information on CI workers without git installed and/or a
> full source checkout.
Doesn't that go against the tendency to have _less_ detailed/private
information in the build? We've lately removed some relatively useful
infos from what we report in commands that use the build information.
More generally, could you present the motivation and the rationale for
making this information available in production builds?
> The things I'm not sure about for this patch are:
> - Is the generating of the version file in the right place in
> Makefile.in
It should be in the build tree, yes.
> - Is the data directory the right place to store the file
Not sure, but I don't see why not.
> - Should the creation of the version file be shared between the Android
> builds and the other platforms
Let's first discuss whether this is at all needed and a good idea,
okay?
> - ${INSTALL_PROGRAM} $(INSTALL_STRIP) src/emacs${EXEEXT} "$(DESTDIR)${bindir}/$(EMACSFULL)"
> + ${INSTALL_PROGRAM} $(INSTALL_STRIP) src/emacs${EXEEXT} "$(DESTDIR)${bindir}/$(EMACS)"
Why this change (and other similar ones)? What does EMACSFULL have to
do with the repository version data?
> @@ -826,6 +837,7 @@ install-man:
> umask 022; ${MKDIR_P} "$(DESTDIR)${man1dir}"
> thisdir=`pwd -P`; \
> cd ${mansrcdir}; \
> + cp ctags.1 gnuctags.1; \
This hunk also looks unrelated.
bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 18 Nov 2024 08:18:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 18 03:18:33 2024
Received: from localhost ([127.0.0.1]:59813 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tCwxs-0004MZ-6B
for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 03:18:33 -0500
Received: from lists.gnu.org ([209.51.188.17]:47194)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <bjorn.bidar@HIDDEN>) id 1tCwxn-0004MN-Un
for submit <at> debbugs.gnu.org; Mon, 18 Nov 2024 03:18:30 -0500
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 <bjorn.bidar@HIDDEN>)
id 1tCwxk-0007Lt-U4
for bug-gnu-emacs@HIDDEN; Mon, 18 Nov 2024 03:18:26 -0500
Received: from thaodan.de ([185.216.177.71])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <bjorn.bidar@HIDDEN>)
id 1tCwxh-0001s9-6r
for bug-gnu-emacs@HIDDEN; Mon, 18 Nov 2024 03:18:24 -0500
Received: from odin (dsl-trebng12-50dc7b-49.dhcp.inet.fi [80.220.123.49])
by thaodan.de (Postfix) with ESMTPSA id 35F25D0005B
for <bug-gnu-emacs@HIDDEN>; Mon, 18 Nov 2024 10:18:13 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail;
t=1731917893; bh=c17MiTNzM9msIl/lPX+kQ2UtRlsldw2JKbO2TiET5zM=;
h=From:To:Subject:Date;
b=ze+Tr27r3ud+Q4RNkPrVgcR67OD28ygrrajoLUpY4Re+eXmgmHLOjRSrIOdp5c495
zzmlECGp1MFXBOfRM3gax6GArByuLyD/MD5w2DyA80D/W6kuxtYHR+FxeIyQ2/X5uh
x15ROZsMUnu/fP/L4bU8/tufNyUfs6UxRvkxYlRtQ+VyhiyaTAH5ymOADYGyJYb2cG
7DW3AEmh1oUdxYpI3V6n2OFHKMdR6euoUt3R4lrB9djkol17/ifrVrRWfSlvsDBCD/
3KL6Lu7Hi55gkhQXiZ8hf5cZYjO09D0MofWuWcX7wl3dCotIXq+jnXhj7dSqJmk0KH
dt8ctCs1am98n3ENOvlyqiYlvxclm57oLHUlLFamsF9ciuxvKGBp32xTr+hqpPjuXj
k+STPb8purhY3XAY8Z4b97uPeEkdgGE4Pb/6bggP/ztqdYe0KRQWF834Z+xJOJHM2x
oY/ckwRrW5UEsOuf4KUVqP9dxhEfFGQLEFurpBiROs6TlhSuOPrOC92If2DJ2HRMSR
+DoGys+cJT1gUSyTK4W8/JD+IQc90t+2jIOZXnOTycL9IkNrsSv7jgKFF+x6FQATis
pOpnRyESrk1t+n+byziQNScrjsyrXjf5QOlqvF0JgwSMm5flHxDqYZu9eNl1KJzDfG
JLOZ+h0BicPKTeCXE1nQChAg=
From: =?utf-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] Allow to store and read repository information of VCS builds
X-Debbugs-Cc:
Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq
w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV
CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl
HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8
phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF
CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h
K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2
cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC
HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN
XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg
gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL
AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E
TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB
B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe
pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO
HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG
AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr
dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n
KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy
GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK
S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA==
Date: Mon, 18 Nov 2024 10:18:11 +0200
Message-ID: <87wmh1j6po.fsf@>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=185.216.177.71;
envelope-from=bjorn.bidar@HIDDEN; helo=thaodan.de
X-Spam_score_int: -14
X-Spam_score: -1.5
X-Spam_bar: -
X-Spam_report: (-1.5 / 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, INVALID_MSGID=0.568,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -0.2 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.2 (-)
--=-=-=
Content-Type: text/plain
Tags: patch
Emacs has the feature to read the repository version and
branch if git is installed during the build and afterwards if also
the sources including the VCS repository is present.
For the Android builds the feature was added to store and read the
information mentioned above in a special version file.
This patch reuses that mechanism so it can be reused on other platforms
to use for the same reasons its available for Android and to also be
able to use the information on CI workers without git installed and/or a
full source checkout.
The things I'm not sure about for this patch are:
- Is the generating of the version file in the right place in
Makefile.in
- Is the data directory the right place to store the file
- Should the creation of the version file be shared between the Android
builds and the other platforms
In GNU Emacs 31.0.50 (build 1, x86_64-suse-linux-gnu, GTK+ Version
3.24.43, cairo version 1.18.2)
Repository revision: eee0ed8442aa78320a3e578ab290df145fb49624
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101014
System Description: openSUSE Tumbleweed
Configured using:
'configure --disable-build-details --without-pop --with-mailutils
--without-hesiod --with-gameuser=:games --with-kerberos
--with-kerberos5 --with-file-notification=inotify --with-modules
--enable-autodepend --enable-link-time-optimization --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--localstatedir=/var --sharedstatedir=/var/lib
--libexecdir=/usr/libexec --with-file-notification=yes
--libdir=/usr/lib64 --with-native-compilation=aot
--enable-locallisppath=/usr/share/emacs/31.0.50/site-lisp:/usr/share/emacs/site-lisp
--with-x --with-xim --with-sound --with-xpm --with-jpeg --with-tiff
--with-gif --with-png --with-rsvg --with-dbus --with-xft --without-gpm
--with-tree-sitter --with-x-toolkit=gtk --without-pgtk
--with-toolkit-scroll-bars --x-includes=/usr/include
--x-libraries=/usr/lib64 --with-libotf --with-m17n-flt --with-cairo
--build=x86_64-suse-linux --with-dumping=pdumper
build_alias=x86_64-suse-linux 'CC=sccache cc' 'CFLAGS=-O2 -Wall
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection
-Werror=return-type -flto=auto -march=znver3 -mmmx -mpopcnt -msse
-msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -msse4a -mno-fma4
-mno-xop -mfma -mbmi -mbmi2 -maes -mpclmul -mno-gfni -mvpclmulqdq
-mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mclwb -mclzero
-mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp
-mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mmwaitx -mno-pconfig -mpku
-mprfchw -mno-ptwrite -mrdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize
-mno-sgx -msha -mshstk -mno-tbm -mno-tsxldtrk -mvaes -mno-waitpkg
-mwbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile
-mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl
-mno-avxvnni -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert
-mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi -mno-raoint
-mno-amx-complex --param l1-cache-size=32 --param l1-cache-line-size=64
--param l2-cache-size=512 -mtune=znver3 -fno-optimize-sibling-calls -O2
-Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection
-Werror=return-type -flto=auto -g -D_GNU_SOURCE
-DGDK_DISABLE_DEPRECATION_WARNINGS -DGLIB_DISABLE_DEPRECATION_WARNINGS
-pipe -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label
-DPDMP_BASE='\''"emacs-gtk"'\''' LDFLAGS=-Wl,-O2 'CXX=sccache c++'
PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
--=-=-=
Content-Type: text/patch
Content-Disposition: attachment;
filename=0001-Allow-to-store-and-read-repository-information-of-VC.patch
From c5332d1a4a65ad6b124d0919d275c0ddde045842 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Bidar?= <bjorn.bidar@HIDDEN>
Date: Sun, 17 Nov 2024 13:37:21 +0200
Subject: [PATCH] Allow to store and read repository information of VCS builds
Store repository information in version file if Emacs is build from
source while VCS is present. The version file can also be stored in the Emacs
sources prior built to indicate if Emacs was built from VCS sources.
An example use case could be if Emacs runs on a system where
the version control system isn't available, e.g. similarly
as it is intended for Android builds.
Another one is to be able to set the VCS information for workers
in a CI environment where sources are generated separately from VCS
but it or the VCS repository isn't present on the worker.
Reuse the same mechanism that exist for Android builds if the version
file is present.
* Makefile.in (etc-emacsver):
Generate etc/version file with revision and branch if git is installed
and Emacs sources are VCS sources.
* lisp/version.el (emacs-repository-get-branch)
(emacs-repository-get-version, emacs-repository-branch-static)
(emacs-repository-version-static):
Implement static versions that can use the information generated during
build if present.
---
.gitignore | 1 +
Makefile.in | 20 ++++++++++++++++----
lisp/version.el | 44 ++++++++++++++++++++++++++++++++------------
3 files changed, 49 insertions(+), 16 deletions(-)
diff --git a/.gitignore b/.gitignore
index c1f31514d06..d3b737d590c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -314,6 +314,7 @@ doc/misc/modus-themes.texi
doc/misc/org.texi
etc/DOC
etc/refcards/emacsver.tex
+etc/version
gnustmp*
/info/
diff --git a/Makefile.in b/Makefile.in
index 30a762ed03b..202b0417282 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -452,7 +452,18 @@ etc-emacsver:
sed "s/[@]majorversion@/$${majorversion}/" \
${srcdir}/etc/refcards/emacsver.tex.in > emacsver.tex.$$$$ && \
${srcdir}/build-aux/move-if-change emacsver.tex.$$$$ \
- ${srcdir}/etc/refcards/emacsver.tex
+ ${srcdir}/etc/refcards/emacsver.tex; \
+ if [ -e $(srcdir)/.git ] && \
+ which git > /dev/null ; then \
+ { (cd $(srcdir) \
+ && git rev-parse HEAD || echo "Unknown") \
+ && (git rev-parse --abbrev-ref HEAD \
+ || echo "Unknown") } 2> /dev/null > \
+ ${top_builddir}/etc/version.$$$$; \
+ ${srcdir}/build-aux/move-if-change \
+ ${top_builddir}/etc/version.$$$$ \
+ ${top_builddir}/etc/version; \
+ else : ;fi
# The shared gamedir name as a C string literal, or a null ptr if not in use.
PATH_GAME = $(if $(use_gamedir),"$(gamedir)",((char const *) 0))
@@ -627,7 +638,7 @@ install-arch-dep:
umask 022; ${MKDIR_P} "$(DESTDIR)${bindir}"
$(MAKE) -C lib-src install
ifeq (${ns_self_contained},no)
- ${INSTALL_PROGRAM} $(INSTALL_STRIP) src/emacs${EXEEXT} "$(DESTDIR)${bindir}/$(EMACSFULL)"
+ ${INSTALL_PROGRAM} $(INSTALL_STRIP) src/emacs${EXEEXT} "$(DESTDIR)${bindir}/$(EMACS)"
ifeq (${HAVE_BE_APP},yes)
${INSTALL_PROGRAM} $(INSTALL_STRIP) src/Emacs "$(DESTDIR)${prefix}/apps/Emacs"
endif
@@ -637,7 +648,7 @@ install-arch-dep:
endif
${INSTALL_DATA} src/emacs.pdmp "$(DESTDIR)${libexecdir}/emacs/${version}/${configuration}"/emacs-${EMACS_PDMP}
endif
- -chmod 755 "$(DESTDIR)${bindir}/$(EMACSFULL)"
+ -chmod 755 "$(DESTDIR)${bindir}/$(EMACS)"
ifndef NO_BIN_LINK
rm -f "$(DESTDIR)${bindir}/$(EMACS)"
cd "$(DESTDIR)${bindir}" && $(LN_S_FILEONLY) "$(EMACSFULL)" "$(EMACS)"
@@ -826,6 +837,7 @@ install-man:
umask 022; ${MKDIR_P} "$(DESTDIR)${man1dir}"
thisdir=`pwd -P`; \
cd ${mansrcdir}; \
+ cp ctags.1 gnuctags.1; \
for page in *.1; do \
test "$$page" = ChangeLog.1 && continue; \
dest=`echo "$${page}" | sed -e 's/\.1$$//' -e '$(TRANSFORM)'`.1; \
@@ -969,7 +981,7 @@ uninstall:
for page in *.1; do \
rm -f "$(DESTDIR)${man1dir}"/`echo "$${page}" | sed -e 's/\.1$$//' -e '$(TRANSFORM)'`.1$$ext; done; \
fi)
- rm -f "$(DESTDIR)${bindir}/$(EMACS)" "$(DESTDIR)${bindir}/$(EMACSFULL)"
+ rm -f "$(DESTDIR)${bindir}/$(EMACS)"
(if cd "$(DESTDIR)${icondir}"; then \
rm -f hicolor/*x*/apps/"${EMACS_NAME}.png" \
"hicolor/scalable/apps/${EMACS_NAME}.svg" \
diff --git a/lisp/version.el b/lisp/version.el
index db2afd55694..3b2c91c03dc 100644
--- a/lisp/version.el
+++ b/lisp/version.el
@@ -171,15 +171,21 @@ emacs-repository-version-git
(looking-at "[[:xdigit:]]\\{40\\}"))
(match-string 0)))))
-(defun emacs-repository-version-android ()
+(defun emacs-repository-version-static (dir)
"Return the Emacs repository revision Emacs was built from.
Value is nil if Emacs was not built from a repository checkout.
-Use information from the `/assets/version' special file."
+Use information from the `DIR/version' special file."
(with-temp-buffer
- (insert-file-contents "/assets/version")
+ (insert-file-contents (expand-file-name "version" dir))
(let ((string (buffer-substring 1 (line-end-position))))
(and (not (equal string "Unknown")) string))))
+(defun emacs-repository-version-android ()
+ "Return the Emacs repository revision Emacs was built from.
+Value is nil if Emacs was not built from a repository checkout.
+Use information from the `/assets/version' special file."
+ (emacs-repository-version-static "/assets"))
+
(defun emacs-repository-get-version (&optional dir _external)
"Try to return as a string the repository revision of the Emacs sources.
The format of the returned string is dependent on the VCS in use.
@@ -194,9 +200,13 @@ emacs-repository-get-version
Optional argument DIR is a directory to use instead of `source-directory'.
Optional argument EXTERNAL is ignored."
- (cond ((and (featurep 'android)
- (eq system-type 'android))
- (emacs-repository-version-android))
+ (cond ((and (or (and (featurep 'android)
+ (eq system-type 'android)
+ (setq dir "/assets"))
+ (and (not dir)
+ (file-exists-p (expand-file-name "version" data-directory))
+ (setq dir data-directory)))
+ (emacs-repository-version-static dir)))
(t (emacs-repository-version-git
(or dir source-directory)))))
@@ -209,8 +219,14 @@ emacs-repository-branch-android
"Return the Emacs repository branch Emacs was built from.
Value is nil if Emacs was not built from a repository checkout.
Use information from the `/assets/version' special file."
+ (emacs-repository-branch-static "/assets"))
+
+(defun emacs-repository-branch-static (dir)
+ "Return the Emacs repository branch Emacs was built from.
+Value is nil if Emacs was not built from a repository checkout.
+Use information from the `DIR/version' special file."
(with-temp-buffer
- (insert-file-contents "/assets/version")
+ (insert-file-contents (expand-file-name "version" dir))
(end-of-line)
(forward-char)
(let ((string (buffer-substring (point) (line-end-position))))
@@ -232,8 +248,8 @@ emacs-repository-get-branch
"Try to return as a string the repository branch of the Emacs sources.
The format of the returned string is dependent on the VCS in use.
-If Emacs is built for Android, use the version information
-embedded in the Emacs installation package.
+If Emacs is built for Android or contains version file,
+use the version information embedded in the Emacs installation package.
Value is nil if the sources do not seem to be under version
control, or if we could not determine the branch. Note that
@@ -241,9 +257,13 @@ emacs-repository-get-branch
correspond to the running Emacs.
Optional argument DIR is a directory to use instead of `source-directory'."
- (cond ((and (featurep 'android)
- (eq system-type 'android))
- (emacs-repository-branch-android))
+ (cond ((and (or (and (featurep 'android)
+ (eq system-type 'android)
+ (setq dir "/assets"))
+ (and (not dir)
+ (file-exists-p (expand-file-name "version" data-directory))
+ (setq dir data-directory)))
+ (emacs-repository-branch-static dir)))
(t (emacs-repository-branch-git
(or dir source-directory)))))
--
2.45.2
--=-=-=--
Björn Bidar <bjorn.bidar@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#74413; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.