Bug#660162: RFS: tack/1.07-2
On Sun, Feb 26, 2012 at 1:35 PM, Samuel Bronson <naesten@gmail.com> wrote:
> 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
Okay, fixed all but the dependency warning:
http://mentors.debian.net/debian/pool/main/t/tack/tack_1.07-1~mentors6.dsc
tack (1.07-1~mentors6) unstable; urgency=low
* New upstream release.
* Adopt package.
Closes: #660140 (ITP for this package).
* Switch to dpkg-source 3.0 (quilt) format.
* Fix "hyphen-used-as-minus-sign" warning from lintian.
* Re-add debian/watch file (was dropped in 1.06-3).
* Enable build warnings.
* Add Vcs-Browser: and Vcs-Git: fields to debian/control.
* Install a symlink CHANGES.gz -> changelog.gz in the doc directory.
* Update debian/copyright to final DEP5 format.
* Use dh-autoreconf to regenerate the configure script during build
+ Build-depends on dh-autoreconf and autoconf-dickey.
+ This also takes care of pulling up-to-date config.guess and config.sub
scripts in from autotools-dev.
+ ... 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 autotools-dev
README.Debian.gz.)
* Add support for dpkg-buildflags(1) by bumping debhelper compatibility
level (and build-depends) to 9.
+ Drop the LDFLAGS="-Wl,-z,defs,-ltic from the call to
dh_auto_configure, so that configure will pick up the LDFLAGS from
dpkg-buildflags(1).
+ Replace it with:
- LIBS="-ltic" as an argument to dh_auto_configure
- DEB_LDFLAGS_MAINT_APPEND for the rest.
Build-Depends: dpkg-dev (>= 1.16.1).
* New patch 03-allow-echoing-compilation-commands.patch, which enables
printing of compilation commands by default.
* Update package to Standards-Version: 3.9.3.
* Thanks to Jakub Wilk for his thorough review.
-- Samuel Bronson <naesten@gmail.com> Fri, 24 Feb 2012 16:22:24 -0500
Reply to: