Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Am 04.08.2019 um 15:58 teilte Jerome BENOIT mit: > On 04/08/2019 17:25, Hilmar Preuße wrote: >> Am 04.08.2019 um 14:09 teilte Gero Treuner mit: Hi Jerome, >>> I verified my assumption that the whole program is not designed for >>> multi-threading: No signs of threading functions or threading library >>> (only in configure stuff, which would support it but unused here). >>> In code the word "thread" is used with other meanings. >>> >>> Also getenv() is used in other places. >>> >>> ==> all fine >>> >> I'd push code then to github. Objections? > > Where ? I mean, can you send a link for the record at least ? > I've pushed the patch now to github to make sure it doesn't get lost. Please be so kind to have a short look. https://github.com/debian-tex/texlive-bin/commit/21560259d0653abe84e1c5a035aabfd8db0cd924 Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
On 04/08/2019 17:25, Hilmar Preuße wrote: > Am 04.08.2019 um 14:09 teilte Gero Treuner mit: > > Hi Jerome, > >> I verified my assumption that the whole program is not designed for >> multi-threading: No signs of threading functions or threading library >> (only in configure stuff, which would support it but unused here). >> In code the word "thread" is used with other meanings. >> >> Also getenv() is used in other places. >> >> ==> all fine >> > I'd push code then to github. Objections? Where ? I mean, can you send a link for the record at least ? Jerome > > H. > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Am 04.08.2019 um 15:58 teilte Jerome BENOIT mit: > On 04/08/2019 17:25, Hilmar Preuße wrote: Hi, >> I'd push code then to github. Objections? > > Where ? I mean, can you send a link for the record at least ? > What record? The patch is here. https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=890734;filename=mp.w_epoch.patch;msg=52 H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Am 04.08.2019 um 14:09 teilte Gero Treuner mit: Hi Jerome, > I verified my assumption that the whole program is not designed for > multi-threading: No signs of threading functions or threading library > (only in configure stuff, which would support it but unused here). > In code the word "thread" is used with other meanings. > > Also getenv() is used in other places. > > ==> all fine > I'd push code then to github. Objections? H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
On Sun, Aug 04, 2019 at 01:40:32PM +0200, Gero Treuner wrote: > Hi > > On Sun, Aug 04, 2019 at 01:18:12PM +0200, Hilmar Preuße wrote: > > > Note: Patch was made against the Buster version > > > (texlive-bin-2018.20181218.49446). > > > > > That's fine. In Debian unstable we had just an offset of 30 lines. > > I applied the patch, compiled the binary and can confirm that is solves > > the problem. > > Great. > > > > I'm not a Debian developer/maintainer, so please check and adopt it > > > according all your procedures (including QA). > > > > > Our coding styles are described here [1]. The only adaption I found was: > > > > Variable declarations > > . > > The declaration of global variables follows analogous rules: they are > > either declared 'static' if used in only one file or declared 'extern' > > in exactly one header and instantiated in exactly one file. > > > > --> As far as I can see your new variable is only one time used in the > > mpost code, hence I declared it to be static. Do you agree here? > > > [1] https://github.com/debian-tex/texlive-bin/blob/master/README.6coding > > The variable is not global, but local to the function which means that > memory is allocated on the stack and automatically freed by return from > the function. Declaring it static would make the variable implicitely > global (and non-reentrant by the way, but not relevant here because > getenv() isn't reentrant anyway). I verified my assumption that the whole program is not designed for multi-threading: No signs of threading functions or threading library (only in configure stuff, which would support it but unused here). In code the word "thread" is used with other meanings. Also getenv() is used in other places. ==> all fine > > The variable should remain local, so left as-is without further > declaration. > > With coding style I slightly adjusted to what I found by inserting a > space after the cast statement. It is best to match the style of the > code surround for readabality. Kind regards, Gero
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Control: tags 890734 + patch Am 04.08.2019 um 00:25 teilte Gero Treuner mit: Hi Gero, > As earlier Metapost user I have it installed and just saw the call for > help while updating my system. > Many thanks! > According to the discussion and supposed plan and SOURCE_DATE_EPOCH > page I have a patch ready (see attachment), which follows the original > coding style. A test looks ok: %%CreationDate: honors the environment > variable, format is the same as before. > > Note: Patch was made against the Buster version > (texlive-bin-2018.20181218.49446). > That's fine. In Debian unstable we had just an offset of 30 lines. I applied the patch, compiled the binary and can confirm that is solves the problem. > I'm not a Debian developer/maintainer, so please check and adopt it > according all your procedures (including QA). > Our coding styles are described here [1]. The only adaption I found was: Variable declarations . The declaration of global variables follows analogous rules: they are either declared 'static' if used in only one file or declared 'extern' in exactly one header and instantiated in exactly one file. --> As far as I can see your new variable is only one time used in the mpost code, hence I declared it to be static. Do you agree here? Regards, Hilmar [1] https://github.com/debian-tex/texlive-bin/blob/master/README.6coding -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Hi all,
As earlier Metapost user I have it installed and just saw the call for
help while updating my system.
According to the discussion and supposed plan and SOURCE_DATE_EPOCH
page I have a patch ready (see attachment), which follows the original
coding style. A test looks ok: %%CreationDate: honors the environment
variable, format is the same as before.
Note: Patch was made against the Buster version
(texlive-bin-2018.20181218.49446).
I'm not a Debian developer/maintainer, so please check and adopt it
according all your procedures (including QA).
Kind regards,
Gero
diff -ur texlive-bin.orig/texk/web2c/mplibdir/mp.w texlive-bin/texk/web2c/mplibdir/mp.w
--- texlive-bin.orig/texk/web2c/mplibdir/mp.w 2019-08-03 22:48:47.0 +0200
+++ texlive-bin/texk/web2c/mplibdir/mp.w 2019-08-03 23:44:23.597334712 +0200
@@ -4350,7 +4350,11 @@
@c
static void mp_fix_date_and_time (MP mp) {
- time_t aclock = time ((time_t *) 0);
+ time_t aclock;
+ char *source_date_epoch;
+ if ((source_date_epoch = getenv("SOURCE_DATE_EPOCH")) == NULL ||
+ (aclock = (time_t) strtoll(source_date_epoch, NULL, 10)) <= 0)
+aclock = time ((time_t *) 0);
struct tm *tmptr = localtime ();
set_internal_from_number (mp_time, unity_t);
number_multiply_int (internal_value(mp_time), (tmptr->tm_hour * 60 + tmptr->tm_min));
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Control: tags 890734 + help
Am 01.08.2019 um 15:26 teilte Hilmar Preuße mit:
> Am 01.08.2019 um 14:36 teilte Jerome BENOIT mit:
>> On 01/08/2019 15:10, Hilmar Preuße wrote:
Hi,
>>> We'd have to calculate human readable time and then split it into
>>> strings to populate the variables,
>>
>> This far harder that it looks.
>>
>> if we want to do it right...
>>
>> Anyway, I think the reverse must be done:
>> modify mp_{year,month,day,time} .
>>
> Sorry, I forgot to mention, that strftime() should be able to not
> just display the whole time string, but also just parts of it.
> Therefore it should be not that hard to populate
> mp_{year,month,day,time} and use it later on.
>
Having said this I still repeat: I'm not a C programmer. Especially when
it comes to string manipulation I'm off. I could try to find a good C
lecture, but for know I prefer to tag that bug help in the hope anybody
volunteers to do the job.
H.
--
sigfault
#206401 http://counter.li.org
signature.asc
Description: OpenPGP digital signature
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Am 01.08.2019 um 14:36 teilte Jerome BENOIT mit:
> On 01/08/2019 15:10, Hilmar Preuße wrote:
Hi,
>> mp_ps_print_nl(mp, "%%CreationDate: ");
>> mp_ps_print_int(mp, round_unscaled(internal_value(mp_year)));
>> mp_ps_print_char(mp, '.');
>> mp_ps_print_dd(mp, round_unscaled(internal_value(mp_month)));
>> mp_ps_print_char(mp, '.');
>> mp_ps_print_dd(mp, round_unscaled(internal_value(mp_day)));
>> mp_ps_print_char(mp, ':');
>> t = round_unscaled(internal_value(mp_time));
>> mp_ps_print_dd(mp, t / 60);
>> mp_ps_print_dd(mp, t % 60);
>>
>> We'd have to calculate human readable time and then split it into
>> strings to populate the variables,
>
> This far harder that it looks.
>
> if we want to do it right...
>
> Anyway, I think the reverse must be done:
> modify mp_{year,month,day,time} .
>
Sorry, I forgot to mention, that strftime() should be able to not just
display the whole time string, but also just parts of it. Therefore it
should be not that hard to populate mp_{year,month,day,time} and use it
later on.
Hilmar
--
sigfault
#206401 http://counter.li.org
signature.asc
Description: OpenPGP digital signature
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Hi Again,
On 01/08/2019 15:10, Hilmar Preuße wrote:
> Am 01.08.2019 um 10:09 teilte Jerome BENOIT mit:
>
> Hi,
>
>> you want to use strftime :
>>
>> https://www.gnu.org/software/libc/manual/html_node/Formatting-Calendar-Time.html
>>
> I'm aware of the functions and I've seen minimal usage examples on
> stackexchange. I'll try again later.
I think it is the wrong way to proceed.
>
>> However,
>> would it not be safer to modify mp_time instead in case mp_time is use
>> elsewhere?
>>
> Original code is:
>
> mp_ps_print_nl(mp, "%%CreationDate: ");
> mp_ps_print_int(mp, round_unscaled(internal_value(mp_year)));
> mp_ps_print_char(mp, '.');
> mp_ps_print_dd(mp, round_unscaled(internal_value(mp_month)));
> mp_ps_print_char(mp, '.');
> mp_ps_print_dd(mp, round_unscaled(internal_value(mp_day)));
> mp_ps_print_char(mp, ':');
> t = round_unscaled(internal_value(mp_time));
> mp_ps_print_dd(mp, t / 60);
> mp_ps_print_dd(mp, t % 60);
>
> We'd have to calculate human readable time and then split it into
> strings to populate the variables,
This far harder that it looks.
if we want to do it right...
Anyway, I think the reverse must be done:
modify mp_{year,month,day,time} .
hth,
Jerome
>
> H.
>
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Am 01.08.2019 um 10:09 teilte Jerome BENOIT mit: Hi, > you want to use strftime : > > https://www.gnu.org/software/libc/manual/html_node/Formatting-Calendar-Time.html > I'm aware of the functions and I've seen minimal usage examples on stackexchange. I'll try again later. > However, > would it not be safer to modify mp_time instead in case mp_time is use > elsewhere? > Original code is: mp_ps_print_nl(mp, "%%CreationDate: "); mp_ps_print_int(mp, round_unscaled(internal_value(mp_year))); mp_ps_print_char(mp, '.'); mp_ps_print_dd(mp, round_unscaled(internal_value(mp_month))); mp_ps_print_char(mp, '.'); mp_ps_print_dd(mp, round_unscaled(internal_value(mp_day))); mp_ps_print_char(mp, ':'); t = round_unscaled(internal_value(mp_time)); mp_ps_print_dd(mp, t / 60); mp_ps_print_dd(mp, t % 60); We'd have to calculate human readable time and then split it into 4 strings to populate the variables, if we want to do it right... H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
On 01/08/2019 11:58, Hilmar Preuße wrote: > Am 31.07.2019 um 20:39 teilte Norbert Preining mit: > > Hi Norbert, > >> But hard-coded rewriting of the actual creating time is wrong. We >> need to do something similar to what pdftex/luatex/xetex/... does. If >> the variable is set it provides a datetime that should be used >> instead of the actual time. >> >> You can look into the first patch by looking at the texlive-bin >> repository with >> git show c832647f4d1fe579fd4eb46ff8b505030b5124db >> > OK, next offer attached. The SOURCE_DATE_EPOCH is now regarded and > verbatim copied into the "%%CreationDate:", when it is set. > > 1. I don't check content of SOURCE_DATE_EPOCH > 2. Not sure if "%%CreationDate: 1265974891" is valid Postscript > > If we need to convert that into human readable string anybody has to > implement it. Sorry, I'm not a C programmer. you want to use strftime : https://www.gnu.org/software/libc/manual/html_node/Formatting-Calendar-Time.html However, would it not be safer to modify mp_time instead in case mp_time is use elsewhere ? Jerome > > H. > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Am 31.07.2019 um 20:39 teilte Norbert Preining mit:
Hi Norbert,
> But hard-coded rewriting of the actual creating time is wrong. We
> need to do something similar to what pdftex/luatex/xetex/... does. If
> the variable is set it provides a datetime that should be used
> instead of the actual time.
>
> You can look into the first patch by looking at the texlive-bin
> repository with
> git show c832647f4d1fe579fd4eb46ff8b505030b5124db
>
OK, next offer attached. The SOURCE_DATE_EPOCH is now regarded and
verbatim copied into the "%%CreationDate:", when it is set.
1. I don't check content of SOURCE_DATE_EPOCH
2. Not sure if "%%CreationDate: 1265974891" is valid Postscript
If we need to convert that into human readable string anybody has to
implement it. Sorry, I'm not a C programmer.
H.
--
sigfault
#206401 http://counter.li.org
Index: texlive-bin/texk/web2c/mplibdir/psout.w
===
--- texlive-bin.orig/texk/web2c/mplibdir/psout.w2019-07-31
23:59:05.712816442 +0200
+++ texlive-bin/texk/web2c/mplibdir/psout.w 2019-08-01 00:00:43.476816442
+0200
@@ -5035,6 +5035,7 @@
void mp_print_initial_comment(MP mp,mp_edge_object *hh, int prologues) {
int t; /* scaled */
char *s;
+ char *source_date_epoch;
mp_ps_print(mp, "%!PS");
if ( prologues>0 )
mp_ps_print(mp, "-Adobe-3.0 EPSF-3.0");
@@ -5055,10 +5056,15 @@
mp_ps_pair_out(mp, hh->minx,hh->miny);
mp_ps_pair_out(mp, hh->maxx,hh->maxy);
}
+ source_date_epoch = getenv("SOURCE_DATE_EPOCH");
mp_ps_print_nl(mp, "%%Creator: MetaPost ");
s = mp_metapost_version();
mp_ps_print(mp, s);
mp_xfree(s);
+ if(source_date_epoch) {
+ mp_ps_print_nl(mp, "%%CreationDate: ");
+ mp_ps_do_print(mp, source_date_epoch, strlen(source_date_epoch));
+ } else {
mp_ps_print_nl(mp, "%%CreationDate: ");
mp_ps_print_int(mp, round_unscaled(internal_value(mp_year)));
mp_ps_print_char(mp, '.');
@@ -5069,6 +5075,7 @@
t = round_unscaled(internal_value(mp_time));
mp_ps_print_dd(mp, t / 60);
mp_ps_print_dd(mp, t % 60);
+ }
mp_ps_print_nl(mp, "%%Pages: 1");
}
signature.asc
Description: OpenPGP digital signature
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Hi Hilmar, > The place where we would have to patch is clear, attached is a first > patch. It disables time stamping in general. Can you tell how to > evaluate the ENV variable SOURCE_DATE_EPOCH? S_D_E is an effort by reproducible-builds initiative, and it is a good idea. But hard-coded rewriting of the actual creating time is wrong. We need to do something similar to what pdftex/luatex/xetex/... does. If the variable is set it provides a datetime that should be used instead of the actual time. You can look into the first patch by looking at the texlive-bin repository with git show c832647f4d1fe579fd4eb46ff8b505030b5124db Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Am 18.02.2018 um 08:16 teilte Jerome Benoit mit: Hi Jerome, > it appears the mpost does not honour SOURCE_DATE_EPOCH: > see attached script. > I'm not sure what the significance of the SOURCE_DATE_EPOCH effort is. Is is just Debian specific or are there more parties, which are trying to build reproducibly? I'm just evaluating if we could submit that bug to upstream or if a possibly patch needs to be developed (and maintained) in Debian. The place where we would have to patch is clear, attached is a first patch. It disables time stamping in general. Can you tell how to evaluate the ENV variable SOURCE_DATE_EPOCH? Hilmar -- sigfault #206401 http://counter.li.org Index: texlive-bin/texk/web2c/mplibdir/psout.w === --- texlive-bin.orig/texk/web2c/mplibdir/psout.w2019-07-31 18:22:53.956816442 +0200 +++ texlive-bin/texk/web2c/mplibdir/psout.w 2019-07-31 18:28:39.212816442 +0200 @@ -5059,8 +5059,8 @@ s = mp_metapost_version(); mp_ps_print(mp, s); mp_xfree(s); - mp_ps_print_nl(mp, "%%CreationDate: "); - mp_ps_print_int(mp, round_unscaled(internal_value(mp_year))); + mp_ps_print_nl(mp, "%%CreationDate: 1970.01.01:00.00"); + /* mp_ps_print_int(mp, round_unscaled(internal_value(mp_year))); mp_ps_print_char(mp, '.'); mp_ps_print_dd(mp, round_unscaled(internal_value(mp_month))); mp_ps_print_char(mp, '.'); @@ -5068,7 +5068,7 @@ mp_ps_print_char(mp, ':'); t = round_unscaled(internal_value(mp_time)); mp_ps_print_dd(mp, t / 60); - mp_ps_print_dd(mp, t % 60); + mp_ps_print_dd(mp, t % 60); */ mp_ps_print_nl(mp, "%%Pages: 1"); } signature.asc Description: OpenPGP digital signature
Bug#890734: texlive-metapost: mpost does not honour SOURCE_DATE_EPOCH
Package: texlive-metapost
Version: 2016.20170123-5
Severity: normal
Dear Maintainer,
it appears the mpost does not honour SOURCE_DATE_EPOCH:
see attached script.
hth,
Jerome
-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource.
In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.
*** The Debian TeX Team is *not* a LaTeX Help Desk ***
If you report an error when running one of the TeX-related binaries
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.
Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.
Don't forget to also include minimal examples of other files that are
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!
If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at
http://www.minimalbeispiel.de/mini-en.html (english)
or
http://www.minimalbeispiel.de/mini.html (german)
##
minimal input file
##
other files
##
List of ls-R files
-rw-r--r-- 1 root root 2538 Feb 5 09:17 /var/lib/texmf/ls-R
-rw-r--r-- 1 root staff 4352 Feb 5 09:17 /usr/local/share/texmf/ls-R
lrwxrwxrwx 1 root root 29 Dec 22 20:12 /usr/share/texmf/ls-R ->
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Dec 22 20:17 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Dec 22 20:17 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
##
Config files
-rw-r--r-- 1 root root 2366 Feb 5 09:09 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Dec 22 20:12 /usr/share/texmf/web2c/fmtutil.cnf ->
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Dec 22 20:12 /usr/share/texmf/web2c/updmap.cfg ->
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 4138 Jun 28 2017
/var/lib/texmf/tex/generic/config/language.dat
##
Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 10 2013 mktex.cnf
-rw-r--r-- 1 root root 2366 Feb 5 09:09 texmf.cnf
##
md5sums of texmf.d
d35d415437f07e8d31d036faa81893ea /etc/texmf/texmf.d/000local.cnf
ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf.disabled
055e06548bac99958d8ab2dd1248f2b4 /etc/texmf/texmf.d/80tex4ht.cnf
1df66bc319cec731e202eaf39f5d85e1 /etc/texmf/texmf.d/96JadeTeX.cnf
-- System Information:
Debian Release: Stretch*
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.12.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages texlive-metapost depends on:
ii tex-common6.06
ii texlive-base 2016.20170123-5
ii texlive-binaries 2016.20160513.41080.dfsg-2
Versions of packages texlive-metapost recommends:
pn feynmf
ii texlive-metapost-doc 2016.20170123-5
texlive-metapost suggests no packages.
Versions of packages tex-common depends on:
ii dpkg 1.18.24
ii ucf 3.0036
Versions of packages tex-common suggests:
ii debhelper 11~bpo9+1
Versions of packages texlive-metapost is related to:
ii tex-common6.06
ii texlive-binaries 2016.20160513.41080.dfsg-2
-- debconf information:
tex-common/check_texmf_missing:
tex-common/check_texmf_wrong:
#!/bin/bash
## RequiredPackage: texlive-metapost
set -e
cat > swirl.mp << EOMP
outputformat:="eps";
prologues:=0;
outputtemplate:="%j.mps";
beginfig(1)
z0 = (0,0);
z1 = (60,40);
z2 = (40,90);
z3 = (10,70);
z4 = (30,50);
draw z0..z1..z2..z3..z4;
endfig;
bye;
EOMP
export SOURCE_DATE_EPOCH=0
mpost swirl.mp > /dev/null
mpost -version | head -n 1
printenv | grep SOURCE_DATE_EPOCH
grep -e '^%%CreationDate' swirl.mps
rm -f swirl.{mp,mps,log}
## eos
