Hello Jörg, On 07-01-15 13:12, Jörg Frings-Fürst wrote: > Am Montag, den 05.01.2015, 21:55 +0100 schrieb Paul Gevers: >> On 30-12-14 21:17, Jörg Frings-Fürst wrote: >>> Am Montag, den 29.12.2014, 11:13 +0100 schrieb Paul Gevers: >>>> On 26-12-14 20:48, Jörg Frings-Fürst wrote: >> Sure, saw that. I guess you want to follow the stable release tree? > > Yes. And eventually the Advanced release in Experimental. Ack. >>>>> * New missing debian/xmlrpc-c-config.man and debian/xmlrpc.man. >>>> >>>> You created these files with help2man. I prefer it when you do this at >>>> build time, so that the man page stays up-to-date. I think you can tweak >>>> the settings of help2man to not add the date and your name. >>>> >>> Yes the manfiles was basically made with help2man, but also massive >>> edited. Therefore I don't build them at build time. >> >> Then I really suggest you remove the first line of the man page file. >> Did you send this manpage upstream then? Ideally you should be able to >> drop this file again once upstream excepts it. Also I suggest to either >> drop the statement about "may be used by others" or improve the wording >> such that you actually really mention a common license name that applies >> to your work on this man page. >> > > Are this ok? > > "This manual page was written by Jörg Frings-Fürst for the Debian > project and is licensed under BSD-3." It is ok for me. Maybe a nicer statement (less ambiguous in the sense that the project has the full license), "is licensed under the same license as xmlrpc-c." >>>> Just wondering (haven't check yet), but you only add symbols files for >>>> amd64 and i386. Is this working correctly with the other archs? Or are >>>> they going to be more strict as a result? >>>> >>> My error. I have differences between amd64 and i386. So I have renamed >>> the symbols file for libxmlrpc-c++8 to *.amd86 and *.i386. >>> >>> I have renamed libxmlrpc-c++8.symbols.amd64 to libxmlrpc-c++8.symbols. >> >> Wouldn't it be possible to merge the symbols files so that the common >> part can still be used (haven't checked the content of the files myself >> yet). >> > No, the symbols file are different between i386 and the other archs. Ok. >> I think you don't need to add the version to the dpkg-gensymbols call, >> and if you do, why strip the Debian part of the version? Doesn't >> dh_makeshlibs call dpkg-gensymbols itself? So if you try to override >> anything, shouldn't the dpkg-gensymbols calls be BEFORE the >> dh_makeshlibs call? This doesn't look right to me. Have you seen >> https://wiki.debian.org/UsingSymbolsFiles where it describes a way to >> create a symbols file that contains as much history as possible? >> > > If the symbols file contains versions with the Debian revision lintian > displays a error[1]. > > No dpkg-gensymbols must run manually. Without the separate call no > symbol files found. With I can found the diffs in the buildlog. > > And yes dpgk-gensymbols must be running befor dh_makeshlibs. Changed. I will do some testing and come back to this. This is not my experience with libraries and symbols files. >>>> Please separate your commits to git to ease review and understanding. >>> >>> ok >> >> Thanks for doing this a bit. However, your commit dbfaa7a7cc is horrible >> to review though, because you mix upstream changes due to the new >> release with your changes. I recommend to have the new upstream release >> in a clean commit and then add your changes nicely documented afterwards. >> > If you want I can make a "git reset" and push the changes separately. Please don't rewrite history in published git repositories, it is considered (for good reasons) bad practice). I'll figure it out, but just keep it in mind for next times (and other projects ;) ). >> It looks like you are mixing ideas in your d/rules file. You export >> DEB_BUILD_MAINT_OPTIONS = hardening=+all, but at the same time you >> declare all the *FLAGS manually (which you shouldn't). Also you don't >> use or export the *FLAGS. I think you should check the last section of >> dpkg-buildflags(1). (I could be wrong here). I think it would make >> 500-mk_gennnmtab.patch unnecessary. > > First I think hardening all is requested for xmlrpc-c. > > Only with "export DEB_BUILD_MAINT_OPTIONS = hardening=+all" > > a get a FTBFS: > > /usr/bin/ld: AbyssServer.osh: relocation R_X86_64_PC32 against symbol `_ZN8xmlrpc_c11AbyssServer10ReqHandler9terminateEv' can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status I reproduce this behavior. > With > > [C|CPP|CXX]FLAGS += -fPIC > > the build runs, but I get by testing with blhc > > CPPFLAGS missing (-D_FORTIFY_SOURCE=2): [..] > > Then with > > [C|CPP|CXX]FLAGS += -fPIC -D_FORTIFY_SOURCE=2 > > blhc display on errors. But still I don't understand it. Shouldn't the flags be exported to be used, so why does this work. Also I think DEB_flag_MAINT_APPEND is meant for this, so I think it is cleaner. > Only lintian says: > > I: libxmlrpc-c++8: hardening-no-fortify-functions usr/lib/x86_64-linux-gnu/libxmlrpc_packetsocket.so.8.39 > > It looks like an error at the makefiles. Would be good if we could find this. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature