On Sun, Feb 26, 2012 at 8:09 AM, Jakub Wilk <jw...@debian.org> wrote: > * Samuel Bronson <naes...@gmail.com>, 2012-02-25, 22:43: > >> + ... except with autoconf-dickey it doesn't, so use autotools-dev's >> dh_ commands; bump build-depends to autotools-dev (>= 20100122.1) >> accordingly. (Yes, even though it says "Do NOT" in the autools-dev >> README.Debian.gz.) > > Typo: autools-dev → autotools-dev.
Oops! >> * Add support for dpkg-buildflags(1) by bumping debhelper compatibility >> level (and build-depends) to 9. > > I wanted to double-check that the hardening flags are actually used, but the > build log is not particularly helpful: > | dh_auto_build > | make[1]: Entering directory `/build/tack-9xzja7/tack-1.07' > | compiling ansi > | compiling charset > | compiling color > | compiling control > | compiling crum > | compiling edit > | compiling fun > | compiling init > | init.c: In function 'reset_init': > | init.c:134:3: warning: ignoring return value of 'system', declared with > attribute warn_unused_result [-Wunused-result] > | compiling menu > | compiling modes > | compiling output > | compiling pad > | compiling scan > | compiling sync > | compiling sysdep > | sysdep.c: In function 'spin_flush': > | sysdep.c:369:4: warning: ignoring return value of 'read', declared with > attribute warn_unused_result [-Wunused-result] > | compiling tack > | linking tack ... > > Could you please make it print actual commands that are being run? (See also > bug #628515.) Hmm, yes, that can be a problem. Unfortunately, it's currently hardwired into the Makefile at configure time; this is likely related to a desire to work with a wider range of Make implementations than is usual? I'll take a look at the source again and/or ask upstream if we can do something like the "make V=yes" thing here... > Later in the build log I see: > | dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided if > "debian/tack/usr/bin/tack" were not uselessly linked against it (they use > none of its symbols). > > It would be nice if you could get rid of this dependency. (But that's OK if > you don't want to.) Yes, I've already reported this upstream[1], and Thomas seemed sympathetic? [1]: http://thread.gmane.org/gmane.comp.lib.ncurses.bugs/4797 Yours gratefully, -- Samuel Bronson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
