From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Bj=C3=B6rn?= Bidar via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74413: [PATCH] Allow to store and read repository information of VCS builds Date: Tue, 19 Nov 2024 08:35:48 +0200 Message-ID: <44439.5463842497$1731998265@news.gmane.org> References: <86frnovhg8.fsf@gnu.org> <867c90vbfk.fsf@gnu.org> Reply-To: =?UTF-8?Q?Bj=C3=B6rn?= Bidar 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="9419"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: luangruo@yahoo.com, 74413@debbugs.gnu.org, Eli Zaretskii To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 19 07:37:37 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 1tDHrk-0002JT-67 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Nov 2024 07:37:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tDHrH-0005NE-Dh; Tue, 19 Nov 2024 01:37:07 -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 1tDHrF-0005Mr-EV for bug-gnu-emacs@gnu.org; Tue, 19 Nov 2024 01:37:05 -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 1tDHrC-00010Q-9k for bug-gnu-emacs@gnu.org; Tue, 19 Nov 2024 01:37:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=WBCPuKrBq8gADo9L//GzSvU/S8/w1MlI9DVFPwHdqSA=; b=BAiXdxIetJt+oeLlSrNaGHo20PgqYvQBZ4WrmZhOr0bu9I0yjoAfBiqTjRQt4glEEfKtU0gv516CZpWiv2T6rM0BCpBcOsIkLvIY1fLSaqiOdCAM4BvvkGvmuzdfz6V4aN7P/m39JkmYzC7e1zuzIgJ9yHQjIFLDmqKum6h+H/SE8P8m6M8h8/rbdsfq3Zi0HmuznbMOJe4KS2xiI6Hzx9frRH9GSgrDrIywHYmeE8lhmt3j+6JJt5tsdiTeudaP8XZFMNYKl43ntiRJch0k2lAS/9ZaBtk4ZQfP1ge53iK0Q3fn8vKqXHe//Eb1ordow+VIC3+4Zbk2h0k8enJ8rA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tDHrB-0004Bl-Vv for bug-gnu-emacs@gnu.org; Tue, 19 Nov 2024 01:37:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Bj=C3=B6rn?= Bidar Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Nov 2024 06:37:01 +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.173199818816039 (code B ref 74413); Tue, 19 Nov 2024 06:37:01 +0000 Original-Received: (at 74413) by debbugs.gnu.org; 19 Nov 2024 06:36:28 +0000 Original-Received: from localhost ([127.0.0.1]:40368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tDHqe-0004Ad-5h for submit@debbugs.gnu.org; Tue, 19 Nov 2024 01:36:28 -0500 Original-Received: from thaodan.de ([185.216.177.71]:35898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tDHqZ-0004AP-0w for 74413@debbugs.gnu.org; Tue, 19 Nov 2024 01:36:26 -0500 Original-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= In-Reply-To: (Stefan Kangas's message of "Mon, 18 Nov 2024 18:48:31 -0500") Autocrypt: addr=bjorn.bidar@thaodan.de; 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 gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlH 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:295626 Archived-At: Stefan Kangas writes: > Eli Zaretskii writes: > >>> From: Bj=C3=B6rn Bidar >>> Cc: Po Lu , 74413@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 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