From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: [PATCH PING] Honor 'SOURCE_DATE_EPOCH' when generating autoloads. Date: Sun, 20 Dec 2015 18:39:04 +0000 Message-ID: References: <87k2ph3mgx.fsf@gnu.org> <87io4lnkyz.fsf@gnu.org> <83mvtwoktg.fsf@gnu.org> <878u5gkakj.fsf@gnu.org> <83a8pwoesc.fsf@gnu.org> <87two3475d.fsf@gnu.org> <5665D6B9.4030309@cs.ucla.edu> <5665DAA1.2080208@cs.ucla.edu> <83k2o9t6t1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1130cd246eb42e052758b0fe X-Trace: ger.gmane.org 1450636783 14440 80.91.229.3 (20 Dec 2015 18:39:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Dec 2015 18:39:43 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 20 19:39:41 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aAitP-0000RQ-RF for ged-emacs-devel@m.gmane.org; Sun, 20 Dec 2015 19:39:40 +0100 Original-Received: from localhost ([::1]:41643 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAitP-0008D6-1c for ged-emacs-devel@m.gmane.org; Sun, 20 Dec 2015 13:39:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAit7-00088t-WB for emacs-devel@gnu.org; Sun, 20 Dec 2015 13:39:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aAit6-0006O3-9y for emacs-devel@gnu.org; Sun, 20 Dec 2015 13:39:21 -0500 Original-Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:36883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAit0-0006LC-Re; Sun, 20 Dec 2015 13:39:15 -0500 Original-Received: by mail-wm0-x229.google.com with SMTP id p187so44191227wmp.0; Sun, 20 Dec 2015 10:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=8P+dfMWuuzbsZIJs/9G2ilJSiE+O0c+ti5B9PgLNums=; b=Y2X1zwqu2wPjPfwUcqRDQowFN/Aa7zYKUR47kIKus4pc1u/v+H97jDf6wzo1Mif1Ls rb2zC1kuswIMRAu1SKfPSGf81IO0xa9WqfUCmub7BLfsyxTDn3bx1FMklB4geoGqJwKD UVU+RI2OFTN/JG8QyZAd89LOF8KPojbQuHnbdo6MJ4H0RolwL1QRUlfuebu1nRl5Z9Ev k8wurGxPKosJ/0Ylhsmz8fMax+i+nDsGWBhO/Bbo+KHOKyY+EdCHSI+JulhmENihrZeI w5S0cYsVEbjj2U0T641qxyhR8MDc/WYPH1I+ZAWlQ62TPkxL47K8UBFK3Ig68s4ewfJH mH/w== X-Received: by 10.194.116.170 with SMTP id jx10mr15789587wjb.166.1450636754201; Sun, 20 Dec 2015 10:39:14 -0800 (PST) In-Reply-To: <83k2o9t6t1.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:196561 Archived-At: --001a1130cd246eb42e052758b0fe Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am So., 20. Dez. 2015 um 17:37 Uhr: > > From: Philipp Stephani > > Date: Sun, 20 Dec 2015 12:48:17 +0000 > > Cc: emacs-devel@gnu.org > > > > Paul Eggert schrieb am Mo., 7. Dez. 2015 um 20:14 > Uhr: > > > > On 12/07/2015 11:00 AM, Philipp Stephani wrote: > > > this would be a rather big change. > > > > I suppose that depends on what one means by "big". To me it feels > like a > > fairly small improvement. We've already made some progress along > these > > lines in emacs-25 by removing emacs-build-system from the result of > the > > emacs-version function; we just need to make more improvements like > that. > > > > It should be in 'master', though, not in 'emacs-25', as it's not > fixing > > a bug. > > > > OK, here's a first patch that replaces system-name with a constant during > > dumping. That eliminates one source of nondeterminism. > > I'm sorry, but I don't like where this is going. I regret I didn't > speak up earlier, but better late than never. > > In a nutshell, I object to losing valuable information for the benefit > of a single specialized use case. I have nothing against supporting > reproducible builds as long as this removes information and data that > is not important to us humans when developing or debugging Emacs. For > example, changes in loaddefs files that remove non-deterministic > information from there or replace it with deterministic information > are fine with me. > > But here we are losing information about the build system that I found > useful more than once in the past when tracking bugs. We have already > removed the build system name from the bug report produced by > report-emacs-bug (I'm going to add it back, btw, unless someone > provides a _very_ good reason for its removal). Earlier, we removed > the last keystrokes, because someone was worried about their privacy, > but couldn't be bothered to delete the sensitive parts from the bug > report. And your comments indicate that you intend to remove the > build time as well, so it will be impossible to say whether a given > binary was built before or after some change. Where is all this > going? > > I'm sorry, but I cannot agree to this slippery slope, just so we could > support a single specialized use case. Let's support that use case by > providing some build-time option, either a configure-time option or a > Makefile option, or an environment variable, or something else. If > someone presents a convincing case, I might even agree to have the > release tarball build by default with that information removed > (although I found it useful in the past when reading bug reports). > But doing this in the development version is simply a non-starter. > When debugging some problem that happened elsewhere, we quite often > need every bit of information that could potentially help us, so > removing it is out of the question. > > I appreciate your efforts in providing the patch, but we will have to > find another way of supporting reproducible builds. > > > Thanks for your feedback. I'm totally happy with making this configurable and turning it off by default. My suggestion would be to use an environment variable EMACS_DETERMINISTIC_BUILD, which is used to initialize a new Boolean variable `deterministic-build'. If the variable is set, the core and Lisp packages would switch to deterministic output. I'd prefer to have this configurable at runtime so that a single Emacs binary can be used to produce both deterministic and non-deterministic output (e.g. for loaddefs). Would that be OK? --001a1130cd246eb42e052758b0fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= So., 20. Dez. 2015 um 17:37=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 20 Dec 2015 12:48:17 +0000
> Cc: emacs-dev= el@gnu.org
>
> Paul Eggert <eggert@cs.ucla.edu> schrieb am Mo., 7. Dez. 2015 um 20:14 Uhr:
>
>=C2=A0 =C2=A0 =C2=A0On 12/07/2015 11:00 AM, Philipp Stephani wrote:
>=C2=A0 =C2=A0 =C2=A0> this would be a rather big change.
>
>=C2=A0 =C2=A0 =C2=A0I suppose that depends on what one means by "b= ig". To me it feels like a
>=C2=A0 =C2=A0 =C2=A0fairly small improvement. We've already made so= me progress along these
>=C2=A0 =C2=A0 =C2=A0lines in emacs-25 by removing emacs-build-system fr= om the result of the
>=C2=A0 =C2=A0 =C2=A0emacs-version function; we just need to make more i= mprovements like that.
>
>=C2=A0 =C2=A0 =C2=A0It should be in 'master', though, not in &#= 39;emacs-25', as it's not fixing
>=C2=A0 =C2=A0 =C2=A0a bug.
>
> OK, here's a first patch that replaces system-name with a constant= during
> dumping. That eliminates one source of nondeterminism.

I'm sorry, but I don't like where this is going.=C2=A0 I regret I d= idn't
speak up earlier, but better late than never.

In a nutshell, I object to losing valuable information for the benefit
of a single specialized use case.=C2=A0 I have nothing against supporting reproducible builds as long as this removes information and data that
is not important to us humans when developing or debugging Emacs.=C2=A0 For=
example, changes in loaddefs files that remove non-deterministic
information from there or replace it with deterministic information
are fine with me.

But here we are losing information about the build system that I found
useful more than once in the past when tracking bugs.=C2=A0 We have already=
removed the build system name from the bug report produced by
report-emacs-bug (I'm going to add it back, btw, unless someone
provides a _very_ good reason for its removal).=C2=A0 Earlier, we removed the last keystrokes, because someone was worried about their privacy,
but couldn't be bothered to delete the sensitive parts from the bug
report.=C2=A0 And your comments indicate that you intend to remove the
build time as well, so it will be impossible to say whether a given
binary was built before or after some change.=C2=A0 Where is all this
going?

I'm sorry, but I cannot agree to this slippery slope, just so we could<= br> support a single specialized use case.=C2=A0 Let's support that use cas= e by
providing some build-time option, either a configure-time option or a
Makefile option, or an environment variable, or something else.=C2=A0 If someone presents a convincing case, I might even agree to have the
release tarball build by default with that information removed
(although I found it useful in the past when reading bug reports).
But doing this in the development version is simply a non-starter.
When debugging some problem that happened elsewhere, we quite often
need every bit of information that could potentially help us, so
removing it is out of the question.

I appreciate your efforts in providing the patch, but we will have to
find another way of supporting reproducible builds.



Thanks for your feedback. I'm = totally happy with making this configurable and turning it off by default. = My suggestion would be to use an environment variable EMACS_DETERMINISTIC_B= UILD, which is used to initialize a new Boolean variable `deterministic-bui= ld'. If the variable is set, the core and Lisp packages would switch to= deterministic output. I'd prefer to have this configurable at runtime = so that a single Emacs binary can be used to produce both deterministic and= non-deterministic output (e.g. for loaddefs). Would that be OK?=C2=A0
--001a1130cd246eb42e052758b0fe--