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 > [email protected]. ..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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
