From: Stefan Kangas <stefankangas@gmail.com>
To: "Eli Zaretskii" <eliz@gnu.org>, "Björn Bidar" <bjorn.bidar@thaodan.de>
Cc: luangruo@yahoo.com, 74413@debbugs.gnu.org
Subject: bug#74413: [PATCH] Allow to store and read repository information of VCS builds
Date: Mon, 18 Nov 2024 18:48:31 -0500 [thread overview]
Message-ID: <CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@mail.gmail.com> (raw)
In-Reply-To: <867c90vbfk.fsf@gnu.org>
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?
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?
next prev parent reply other threads:[~2024-11-18 23:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87wmh1j6po.fsf@>
2024-11-18 12:45 ` bug#74413: [PATCH] Allow to store and read repository information of VCS builds Eli Zaretskii
2024-11-18 14:21 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <875xoklj13.fsf@>
2024-11-18 14:55 ` Eli Zaretskii
2024-11-18 16:54 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87frnowkhp.fsf@>
2024-11-18 19:03 ` Eli Zaretskii
2024-11-18 19:31 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <874j44wd7k.fsf@>
2024-11-18 19:41 ` Eli Zaretskii
2024-11-18 21:48 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87y11g5i2x.fsf@>
2024-11-19 15:16 ` Eli Zaretskii
2024-11-19 16:13 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-19 17:08 ` Eli Zaretskii
2024-11-20 7:55 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-18 23:48 ` Stefan Kangas [this message]
2024-11-19 6:35 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-19 15:19 ` Eli Zaretskii
2024-11-19 16:16 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-19 17:20 ` Eli Zaretskii
2024-11-18 8:18 Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADwFkmnNqFsQunZ5BcUDT3gPh7A6tQ84X-=MopU-NicTXOvccA@mail.gmail.com' \
--to=stefankangas@gmail.com \
--cc=74413@debbugs.gnu.org \
--cc=bjorn.bidar@thaodan.de \
--cc=eliz@gnu.org \
--cc=luangruo@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).