Bug#1073456: Sponsoring colorize into Debian

[Steven Schubiger <stsc@refcnt.org>]

Pierre Gruet <pgt@debian.org> wrote:
> I am sponsoring right now your package colorize/0.66 into Debian, as you
> submitted it on mentors.debian.org last month.

Thank you so much! :)

> I will juste change the version number in debian/watch : 3 to 4.

Yeah, that makes sense.  It makes less sense (to me) to amend it right now
by committing to cgit.refcnt.org as a future release for Debian will require
changes to debian/ anyhow.

> Also when building I got the Lintian warning
> 
> I: colorize: file-references-package-build-path [usr/bin/colorize]
> N:
> N:   The listed file or maintainer script appears to reference the build
> path
> N:   used to build the package as specified in the Build-Path field of the
> N:   .buildinfo file.
> N:
> N:   This is likely to cause the package to be unreproducible, but it may
> also
> N:   indicate that the package will not work correctly outside of the
> N:   maintainer's own system.
> N:
> N:   Please note that this tag will not appear unless the .buildinfo file
> N:   contains a Build-Path field. That field is optional. You may have to
> set
> N:   DEB_BUILD_OPTIONS=buildinfo=+path or use
> N:   --buildinfo-option=--always-include-path with dpkg-buildpackage when
> N:   building.
> N:
> N:   Please refer to https://reproducible-builds.org/,
> N:   https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles, and the
> N:   dpkg-genbuildinfo(1) manual page for details.
> N:
> N:   Visibility: info
> N:   Show-Always: no
> N:   Check: files/contents
> 
> which indicates that the executable embeds some path of the system it was
> built on. It would be good to manage it so that the build is independent of
> the place it happens in, in order to enhance build reproducibility and to be
> sure it will work on whatever computer.

colorize's version output (`-V/--version`) looks currently as follows:

  colorize v0.65 (compiled at Mar 20 2020, 21:42:04)
  Compiler flags: "-ansi -pedantic -g -O2 -fdebug-prefix-map=/build/colorize-K9pfPs/colorize-0.65=. -fstack-protector-strong -Wformat -Werror=format-security"
  Linker flags: "-Wl,-z,relro -Wl,-z,now"
  Preprocessor flags: "-Wdate-time -D_FORTIFY_SOURCE=2"
  Buffer size: 4K
  Color separator: '/'
  Debugging: no

I suspect it is the argument to -fdebug-prefix-map that's causing trouble, correct?

The flags above get defined within colorize.c by the "colorize" Makefile target,
which consists of -DCCPFLAGS, -DCFLAGS and -DLDFLAGS (among other ones):

  colorize:	colorize.c
  			perl ./version.pl > version.h
  			$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o colorize colorize.c \
   -DCPPFLAGS="\"$(CPPFLAGS)\"" -DCFLAGS="\"$(CFLAGS)\"" -DLDFLAGS="\"$(LDFLAGS)\"" \
   -DHAVE_VERSION $(FLAGS)

And finally, colorize.c has these statements:

  printf ("Compiler flags: %s\n", c_flags);
  printf ("Linker flags: %s\n", ld_flags);
  printf ("Preprocessor flags: %s\n", cpp_flags);

I could imagine omitting embedding such paths through a define and thus make it
optional for certain builds (still, I'd like to keep it for personal uses... :).

Last, but not least there's even more "problematic" code:

  printf ("%s %s%s (compiled at %s, %s)\n", PROGRAM_NAME, version_prefix, version_string, __DATE__, __TIME__);
                                                                                          ^^^^^^^^  ^^^^^^^^
Probably it would be best, to "fix" all such occurrences; otherwise, they're likely
to cause some further trouble in the unforeseen future...

> Thanks for your wokr on this!

Welcome :)

Hope this helps,
  
-stsc