[tlbuild] dvisvgm

[Mojca Miklavec]

On 9 February 2017 at 11:12, Martin Gieseking wrote:
> Hello Mojca,
>
>> Are you saying that the Debian devs didn't complain about
>> non-reproducible builds yet? :)
>>
>> See:
>>     https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal
>
> No, not yet. :) The format of the timestamp doesn't really matter here. It's
> just added to the footer of some of the manpage output formats (pdf, html).

I'm not necessarily talking about the format of the timestamp. But
"print current timestamp" is a "no go" in any case (I guess that was
your proposal for the replacement of "stat -c %y"). From what I
understand you print the timestamp of last modification of the file.
That should work better. The only requirement is that two people
building on a different locale at different times with *the same*
compiler should get the same files at the end. If that's already the
case, you may ignore what I wrote, let's just make sure that it works
on Mac in a way that won't include the timestamp of the build. (I
don't get a Slovenian date when I run "stat" :)

>> While "stat -f %Sm" works in principle, the patched Makefile[.in]
>> doesn't quite make it (I also tried to replace "stat -c %y $<" by
>> "stat -f %Sm", but I keep getting some "extra characters at the end of
>> d command"):
>>
>> if [ `type -p asciidoc` ]; then \
>> asciidoc -a icons -a 'iconsdir=.' -a badges -a 'revnumber=2.1.1'
>> --unsafe -bdocbook -dmanpage -o dvisvgm-man.xml dvisvgm.txt; \
>> sed -i "s#\(</refmeta>\)#<refmiscinfo class='date'>Feb  9 10:37:32
>> 2017</refmiscinfo>\n\1#" dvisvgm-man.xml; \
>> fi
>> sed: 1: "dvisvgm-man.xml": extra characters at the end of d command
>
> Hm, that's strange. I don't know where the "d" command comes from. There are
> only "s" commands in the sed statements...

The first letter of "dvisvgm-man.xml" is "d" for example. It could be
that something went wrong when executing/quoting the commands.

> I'm also wondering why "make" tries to rebuild dvisvgm-man.xml at all.
> dvisvgm.1 should be present in the source tarball so that there's no need to
> rebuild it.

I can confirm that it's present, but I'm not sure how to debug *why*
the file is being built.

If you need the full log, please let me know.

>> One more question. I notice that the binary links against
>>     $prefix/lib/libgs[.X.Y].dylib
>> when I build it on a system with a number of preinstalled packages
>> (actually within the scope of a package manager). Dick's binary was
>> built on a clean system from TL directly and doesn't have any strange
>> dependencies.
>>
>> Where exactly does that dependency on libgs get pulled in?
>
> Unfortunately, I don't own a Mac and have no deeper knowledge of macOS.
> Thus, I can't really help you with this one.

I now see

HAVE_LIBGS=1
AC_CHECK_HEADER([ghostscript/iapi.h],
    AC_CHECK_LIB(gs, gsapi_new_instance, , HAVE_LIBGS=0), HAVE_LIBGS=0)

in the sources. Is this something that one can influence (for example
with --disable-gs / --without-gs)? And when should the gs library be
used? Is it a problem if it's not used in the TL build? Should it be
used in the package manager?

Thank you,
    Mojca