bug#74413: [PATCH] Allow to store and read repository information of VCS builds

["Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>>> Cc: Po Lu <luangruo@yahoo.com>,  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örn Bidar <bjorn.bidar@thaodan.de> 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 pdump
>> 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] 

> 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, guix
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