Re: blt repackaged again, please advise on last lintian warnings
On Wed, Mar 6, 2013 at 12:32 PM, Markus Wanner <markus@bluegap.ch> wrote:
> Paul,
>
> I'm not a DM/DD, but I'll try to help.
>
Thanks! Thats very kind of you to spend your time and share the knowledge.
> On 03/05/2013 05:34 AM, Paul Johnson wrote:
>> Hi, everybody. I'm back, now humbled by linitian's might. Instead
>> of putting my blt package revisions onto the mentors server, and
>> probably wasting your storage on another not-yet-done package, I
>> uploaded my new effort here:
>>
>> http://pj.freefaculty.org/Debian/wheezy/amd64/blt-GK-3/
>
> If you provide a link to the .dsc file directly, you save your
> recipients the directory lookup step. dget can fetch it all via the .dsc
> file.
>
>> 1-2 I need you to tell me the protocol. I intend to adopt, Its not an
>> NMU. Is it? I solve warnings if I mark it as a Nonmaintainer Upload
>> and then change the release to a fractional 6.1.
>
> Adopting the package would make sense, I think. That would mean you add
> yourself as a Maintainer: in debian/control.
>
> Please consider collaborating with others, i.e. forming a team that can
> then maintain the package together. This increases chances of at least
> one of the team reacting.
>
> Once you or a team including you is the maintainer, you can assign
> non-NMU release versions. (Another very minor nit-pick: 6.1 isn't a
> fraction, as 6.10 is several versions newer than 6.1.)
>
> Where has version 2.4z-5 gone, BTW?
>
version 5 is the version we've been using "around here" for a few
years. There never was an official -5 in Debian, of course, and I'm
starting to see why.
>
>> 3 is an objection against the package name, which is currently blt,
>> but perhaps it might be changed to libblt. But I don't want to. What a
>> hassle.
>
> Yeah, renaming is a bit of a hassle.
>
> blt4.2 and blt8.0, that your package conflicts with, are that blt
> library built against tk 4.2 and 8.0, respectively, right?
>
> Don't you need to keep a version number as well, i.e. naming the thing
> libblt2.4 (if libblt2.5 is not backward compatible) or libblt2 (if
> libblt2.5 is, but not libblt3).
>
> Maybe it's okay or common for tk/tcl packages to skip the 'lib' prefix?
> I'm not a Tcl/Tk user. You could add a lintian override, in that case.
>
>> 4-11 are compiler flags, but I don't know how to fiddle the rules file.
>
> The custom CONFIGURE line overrides the CFLAGS from dpkg-buildflags (via
> DPKG_EXPORT_BUILDFLAGS = 1). Something along this lines seems to help:
>
> diff -aur blt-2.4z/debian/rules blt-2.4z.patched/debian/rules
> --- blt-2.4z/debian/rules 2013-03-03 08:21:03.000000000 +0100
> +++ blt-2.4z.patched/debian/rules 2013-03-06 09:11:58.686697255 +0100
> @@ -4,7 +4,6 @@
> # This has to be exported to make some magic below work.
> export DH_OPTIONS
>
> -DEB_BUILD_MAINT_OPTIONS=hardening=+all
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/buildflags.mk
>
> @@ -13,9 +12,8 @@
>
> dtmp = $(shell pwd)/debian/tmp
>
> -CONFIGURE = ./configure --prefix=/usr/ --mandir=/usr/share/man \
> - --with-cflags="-O2 -g -D_REENTRANT "
> -
> +CONFIGURE=./configure --prefix=/usr/ --mandir=/usr/share/man
> +CFLAGS+=-D_REENTRANT
>
> # Now, the build targets...
>
>
> Two things to mention here: that I stripped "-O2 -g" as well, because
> these are defaults, anyway. "hardening=+all" causes -fPIE to be added to
> the CFLAGS, which in turn causes compilation errors, so I dropped that line.
>
Let me double check that you see same. After putting in the change you
do, lintian still hates me:
W: blt: hardening-no-relro usr/lib/libBLT.2.4.so.8.4
W: blt: hardening-no-fortify-functions usr/lib/libBLT.2.4.so.8.4
W: blt: hardening-no-relro usr/lib/libBLT.2.4.so.8.5
W: blt: hardening-no-fortify-functions usr/lib/libBLT.2.4.so.8.5
W: blt: hardening-no-relro usr/lib/libBLTlite.2.4.so.8.4
W: blt: hardening-no-fortify-functions usr/lib/libBLTlite.2.4.so.8.4
W: blt: hardening-no-relro usr/lib/libBLTlite.2.4.so.8.5
W: blt: hardening-no-fortify-functions usr/lib/libBLTlite.2.4.so.8.5
I put back in all the hardening options, except pie, still same result.
I did not understand your next point about LDFLAGS, but now I am
starting to understand. The flags are happening because the flags
"-Wl,-z,relro" are not getting tacked onto the end of the linker
command. You think that's the problem?
> In a similar vein, LDFLAGS doesn't get passed through to SHLIB_LD_FLAGS
> in src/shared/Makefile. There's a vast amount of patching done to the
> configure and Makefiles in 02-debian-all.diff, already. And I couldn't
> quickly figure out how to correct that.
>
Me neither. All that stuff is from the previous package maintainers.
>> 12-13 are unsolvable without make some pretty deep, unpredictable
>> changes in the source itself. There are scripts that use those two
>> image files as "busy cursor" icons, and the path is hard coded into
>> them.
>
> Changing a hard-coded path doesn't sound like a deep, unpredictable
> change to me.
Well, if I had written this code, I might be able to predict &
understand the effect of a change like that. As it is, wouldn't you
rather leave the image file in a place you know actually runs?
>
>> 14-17 seem peculiar to me. Aren't the necessary symlinks created by
>> ldconfig after the package files are installed? It shouldn't matter
>> if the links are in the package at all. Just my opinion.
>
> It's required per Debian Policy, 8.4. I guess one reason for it is to be
> able to explicitly select the version of a library to develop against
> via package installation. I.e. let the lib*.so link point to an older
> version.
>
>> I understand that, when I eventually upload it to mentors, I'll get
>> instructions on requesting a sponsor via email to the bug number
>> 664092@bugs.debian.org.
>
> ..via email to you, directly. I think it's a good idea to keep track of
> progress on your ITA bug, though.
>
>
> That's based on what I've learned so far. Please feel free to correct me.
>
Thanks very much for your help. Supposing that the hardening warnings
are related to the linker thing, maybe I can find a way to slide in
those flags and see if the warnings are solved. Just for fun.
pj
> Regards
>
> Markus Wanner
--
Paul E. Johnson
Professor, Political Science Assoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org http://quant.ku.edu
Reply to: