Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Norbert Preining]

Hi all,

I did the following:

tex.man:
added to the ENVIRONMENT section:
+.P
+Notes for Debian developers: please keep in mind, that this version of
+the \*(TX interpreter ignores the
+.B SOURCE_DATE_EPOCH
+variable. Instead the current timestamp is written into the
+.I DVI
+file. If you need a reproducible time stamp, please use any engine based
+on pdf\*(TX, e.g., etex, pdftex, latex, pdflatex.


etex.man:
added to the ENVIRONMENT section:
+.TP
+.B SOURCE_DATE_EPOCH
+If set, its value, taken to be in epoch-seconds, will be used for the
+timestamps in the PDF output, such as the CreationDate and ModDate keys.
+This is useful for making reproducible builds.
+.TP
+.B FORCE_SOURCE_DATE
+If set to the value "1", the time-related \*(TX primitives
+.RI ( \eyear ,
+.IR \emonth ,
+.IR \eday ,
+.IR \etime )
+are also initialized from the value of SOURCE_DATE_EPOCH.  This is not
+recommended if there is any viable alternative.


Hope that is fine with you

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Bill Allombert]

On Fri, May 04, 2018 at 11:56:43PM +0900, Norbert Preining wrote:
> Hi Bill,
> 
> > > tex is tex as DEK wanted it. Please use etex, which is the pdftex binary
> > > producing dvi.
> 
> Well, tex the name has already a copyright that makes this necessary.
> 
> > Maybe this could be documented in the manpage ? There is already:
> 
> Any suggestion for a paragraph?

To start with etex man page could list SOURCE_DATE_EPOCH and
FORCE_SOURCE_DATE in the ENVIRONMENT section of the manpage
as pdftex does.

Secondly the tex manpage could give a nod to etex for users
with "special" requirement (I did not know about etex, there
are so many "extended tex" program.

Cheers,
Bill.

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Hilmar Preuße]

On 04.05.2018 13:38, Bill Allombert wrote:

Hi Bill,

> Maybe this could be documented in the manpage ? There is already:
> 
> BUGS
>This version of TeX implements a number of optional extensions.
>   In fact, many of these extensions  conflict  to  a  greater or lesser
>   extent with the definition of TeX.  When such extensions are enabled,
>   the banner printed when TeX starts is  changed  to  print TeXk instead
>   of TeX.
> 
> I think it is likely that if this bug is closed without changes, someone
> else will open it again.
> 
How about the attached patch for tex.1?

Hilmar
-- 
#206401 http://counter.li.org
--- tex.1	2017-03-30 03:02:29.0 +0200
+++ tex.2	2018-05-04 20:25:46.053590373 +0200
@@ -474,6 +474,14 @@
 but when it does the generated
 .I DVI
 file will be invalid.
+.PP
+Notes for Debian developers: please keep in mind, that this version of
+the \*(TX interpreter ignores the
+.B SOURCE_DATE_EPOCH
+variable. Instead the current timestamp is written into the
+.I DVI
+file. If you need a reproducible time stamp, please use the pdf\*(TX
+interpreter, which is used e.g. by \*(LX.
 .\"=
 .SH "SEE ALSO"
 .BR mf (1),

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Norbert Preining]

> Developpers generally expect every programs that generates files with
> timestamp to honor SOURCE_DATE_EPOCH at some point.

Huuu? SDE was introduced really recently, I wouldn't say that
someone *generally* expect it to work. I (as developer) don't expect it. 
It is pushed by a certain initiative, it has a reason of existence, but
I wouldn't call it standard, by far.

> However, if this is not clearly documented, developpers might report
> this wishlist again and again.

And I will close it again and again. I have a rather rough stance
concerning the BTS. Too many rubbish bugs accumulating (well, ok, it is
still much better than Ubuntu, but still often a PITA where the problem
is between chair and keyboard).

Do you really think *any* developer will read man pages or README.Debian
to find out whether program xyz supports SDE? I would be surprised.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Norbert Preining]

Hi Bill,

> > tex is tex as DEK wanted it. Please use etex, which is the pdftex binary
> > producing dvi.

Well, tex the name has already a copyright that makes this necessary.

> Maybe this could be documented in the manpage ? There is already:

Any suggestion for a paragraph?

> I think it is likely that if this bug is closed without changes, someone
> else will open it again.

Then again, it is about knowing the TeX & friends setup, which is not
completely trivial a thing.

> What about latex ?

latex is a format, and since some years already requires the etex
extensions, so if you run any kind of latex you know that it will
necessarily have etex extensions. That is, with latex/pdflatex you are
using the pdfetex engine, which has support for SDE.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Bill Allombert]

On Fri, May 04, 2018 at 02:00:26PM +0200, Hilmar Preuße wrote:
> On 04.05.2018 13:38, Bill Allombert wrote:
> 
> Hi,
> 
> > Maybe this could be documented in the manpage? There is already:
> > 
> > BUGS
> >This version of TeX implements a number of optional extensions.
> >   In fact, many of these extensions  conflict  to  a  greater or lesser
> >   extent with the definition of TeX.  When such extensions are enabled,
> >   the banner printed when TeX starts is  changed  to  print TeXk instead
> >   of TeX.
> > 
> Hmm, you mean we should document every difference between our TeXk and
> TeX? Not sure if that should be put into a /manual/ page.
> 
> > I think it is likely that if this bug is closed without changes, someone
> > else will open it again.
> > 
> What bug?

Sorry, I meant bug as in 'an entry in the Debian BTS' not as "a problem
that need to be solved". And actually #897627 is a wishlist item.

Developpers generally expect every programs that generates files with
timestamp to honor SOURCE_DATE_EPOCH at some point.
That tex will not implement it for legacy reason, and that etex needs to
be used instead is OK, even if potentially inconvenient (if tex is
hardcoded in upstream makefile).

However, if this is not clearly documented, developpers might report
this wishlist again and again.

Cheers,
Bill.

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Hilmar Preuße]

On 04.05.2018 13:38, Bill Allombert wrote:

Hi,

> Maybe this could be documented in the manpage? There is already:
> 
> BUGS
>This version of TeX implements a number of optional extensions.
>   In fact, many of these extensions  conflict  to  a  greater or lesser
>   extent with the definition of TeX.  When such extensions are enabled,
>   the banner printed when TeX starts is  changed  to  print TeXk instead
>   of TeX.
> 
Hmm, you mean we should document every difference between our TeXk and
TeX? Not sure if that should be put into a /manual/ page.

> I think it is likely that if this bug is closed without changes, someone
> else will open it again.
> 
What bug? According to Norbert the behavior of TeX is more close the
DEK's TeX than pdfTeX. So one could complain about a bug in pdfTeX, but
not in TeX (as you did).
We could implement a README.Debian  documenting, which version of TeX to
use, when one needs a reproducible build.

> What about latex?
> 
hille@amd64-sid:~$ latex
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018/Debian)
(preloaded format=latex)
 restricted \write18 enabled.
**^C
hille@amd64-sid:~$ tex
This is TeX, Version 3.14159265 (TeX Live 2018/Debian) (preloaded
format=tex)
**^C

--> uses pdfTeX.

H.
-- 
#206401 http://counter.li.org

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Bill Allombert]

On Fri, May 04, 2018 at 12:37:36PM +0900, Norbert Preining wrote:
> Hi Bill,
> 
> On Thu, 03 May 2018, Bill Allombert wrote:
> > While pdftex handles SOURCE_DATE_EPOCH, tex does not, which leads to
> > unreproducible DVI files.
> 
> tex is tex as DEK wanted it. Please use etex, which is the pdftex binary
> producing dvi.

Maybe this could be documented in the manpage ? There is already:

BUGS
   This version of TeX implements a number of optional extensions.
  In fact, many of these extensions  conflict  to  a  greater or lesser
  extent with the definition of TeX.  When such extensions are enabled,
  the banner printed when TeX starts is  changed  to  print TeXk instead
  of TeX.

I think it is likely that if this bug is closed without changes, someone
else will open it again.

What about latex ?

Cheers,
Bill.

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Norbert Preining]

Hi Bill,

On Thu, 03 May 2018, Bill Allombert wrote:
> While pdftex handles SOURCE_DATE_EPOCH, tex does not, which leads to
> unreproducible DVI files.

tex is tex as DEK wanted it. Please use etex, which is the pdftex binary
producing dvi.

Can I close this bug?

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Bill Allombert]

Package: texlive-binaries
Version: 2018.20180416.47457-1
Severity: wishlist

While pdftex handles SOURCE_DATE_EPOCH, tex does not, which leads to
unreproducible DVI files.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.