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! :) > 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
