On Wed, Mar 6, 2013 at 12:32 PM, Markus Wanner <[email protected]> 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 >> [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. > 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAErODj97pFATE6c-xaGLg2eOO=ex2pe0p2jghk76tmk5ea3...@mail.gmail.com
