Bug#1073456: Sponsoring colorize into Debian

[Pierre Gruet]

Hi Steven,

Le 14/07/2024 à 16:51, Steven Schubiger a écrit :

Pierre Gruet <p...@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! :)

You're welcome :)

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.

Sure! Honestly, even if you forgot that and kept version=3, it would not be that important; it is just a matter of compliance since this does not change anything for this somehow simple d/watch file. For next upload, look at the source of the package I uploaded today, you will see I added a line in d/changelog about the version bump of d/watch.

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...

https://sources.debian.org/src/atomes/1.1.14-1.1/debian/patches/omit_flags_in_binary.patch/


$ dpkg-parsechangelog -SDate
instead of the __DATE__ and __TIME__ macros.

Thanks for digging into this matter. Yes, keeping the flags is something I have already seen. If you don't want to fix it in your main software, it could be patched in Debian, I have already done this sort of things e.g. in And yes, __DATE__ and __TIME__ are also sources of non-reproducibility; if this remains as is, I think we could also patch this code in Debian by putting information from

Thanks for your wokr on this!

Welcome :)

Hope this helps,

Sure, thanks for digging into this :)

-stsc

Best,

--
Pierre

OpenPGP_signature.asc
Description: OpenPGP digital signature