[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#660162: RFS: tack/1.07-2



On Sun, Feb 26, 2012 at 8:09 AM, Jakub Wilk <jwilk@debian.org> wrote:
> * Samuel Bronson <naesten@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



Reply to: