From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#74413: [PATCH] Allow to store and read repository information of VCS builds Date: Mon, 25 Nov 2024 15:43:41 -0800 Message-ID: References: <86frnovhg8.fsf@gnu.org> <867c90vbfk.fsf@gnu.org> <673c31c6.a70a0220.18f62b.10d8SMTPIN_ADDED_BROKEN@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3834"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 74413@debbugs.gnu.org, Eli Zaretskii To: =?UTF-8?Q?Bj=C3=B6rn?= Bidar Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 26 00:45:34 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tFilo-0000nf-1k for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Nov 2024 00:45:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tFilT-0004oR-K7; Mon, 25 Nov 2024 18:45:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tFilR-0004nH-4C for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2024 18:45:09 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tFilL-000560-KX for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2024 18:45:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:MIME-Version:References:In-Reply-To:From:To:Subject; bh=H9gsgMMAo4ZSB/rvVvbxM22VpeLGZ9pzs0CKLx+x1jU=; b=eMfVpF77kfWFvQb2wS/NxEFy4Ky3sGOlDkIZ8Ylv45xDXe/OmVe2Y8TwfvevkjT4aivcZZuKUQ1H1bQ8xxTW1aVVI59SmYvClCqAUlLH5xH13ILVNc45xu5ikK4gD5qYR5R+YY0YFn2Dl1gAvklH9d1j2cNB8FMke4ydGmkXzXZ4awkMVLaBEaKUOn7Wfqsr9dOczbvGi9hJXg8pzcF1sGb8tT05nfPe9JhdQpHdXojdy0FySyaQbSkYX0yucYHlCRqPNxr9vJQ3YQOVcrUcbFUcqZGAoGKfQh9iaW6tUFC7CfIrLycGQT24WeF+f/Q6QhCTFBltKijlgbL42F0m+A==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tFilK-0004AR-Q6 for bug-gnu-emacs@gnu.org; Mon, 25 Nov 2024 18:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Nov 2024 23:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74413 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74413-submit@debbugs.gnu.org id=B74413.173257828615955 (code B ref 74413); Mon, 25 Nov 2024 23:45:02 +0000 Original-Received: (at 74413) by debbugs.gnu.org; 25 Nov 2024 23:44:46 +0000 Original-Received: from localhost ([127.0.0.1]:43121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFil3-00049D-ST for submit@debbugs.gnu.org; Mon, 25 Nov 2024 18:44:46 -0500 Original-Received: from mail-wr1-f51.google.com ([209.85.221.51]:58558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFil2-000495-0x for 74413@debbugs.gnu.org; Mon, 25 Nov 2024 18:44:44 -0500 Original-Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-3823e45339bso3716619f8f.0 for <74413@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) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 25 Nov 2024 15:43:41 -0800 In-Reply-To: <673c31c6.a70a0220.18f62b.10d8SMTPIN_ADDED_BROKEN@mx.google.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295968 Archived-At: Bj=C3=B6rn Bidar 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.