Re: blt repackaged again, please advise on last lintian warnings
Paul,
I'm not a DM/DD, but I'll try to help.
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?
> By the way, last week on mentors I uploaded 2.4z-6. When I upload
> again, should I use 2.4z-6 again?
I was told that's a bit up to you. I'd currently recommend keeping track
of your work separately with your favorite kind of VCS and only
increment the version after a real release. Otherwise version numbers
get real big too soon.
> 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.
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.
> 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.
> 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.
Regards
Markus Wanner
Reply to: