Laszlo, On 08/05/2012 10:46 AM, Laszlo Boszormenyi (GCS) wrote: > On Sat, 2012-08-04 at 23:53 +0400, Vsevolod Stakhov wrote: >> Thanks for taking care of it! I'm using this package for my machines, >> but I'm not very familiar with debian packaging policies unfortunately. > Hmmm, do you really want to learn and package it? Learning is always > good, I don't want to hijack it from you.
Well, I've fixed all issues you pointed and committed them to rspamd mercurial repository. I think I'll release 0.5.1 version soon and the package would be for it, not for 0.5.0. >> It's strange as rspamd is built with -fpic -fPIC flags if they are >> supported on the targeted architecture. How can I repeat this bug using >> my debian system? > Sure, I've seen that you use -fpic and -fPIC as well for compilation. > The patch I've sent to you contains everything. Just uncomment the > export DEB_BUILD_MAINT_OPTIONS=hardening=+all > line in debian/rules . I think one of your source files might not be > compiled with the PIC flags and that's the problem. Well, I've tried the same on my ubuntu dev box and cannot repeat this issue. Can you please try it again with modified package? >> Library is only used for rspamd client (rspamc), so maybe it would be >> better to link it statically for debian package? I think a development >> package is only useful when there is any external software that uses the >> normal package's API. > I do agree with your lines. Either make the binary statically linked > and without the header file or consider the package split. Do you intend > to use plug-ins or whatever external to spamc? There's no problem if > nobody else will use the separated library, but it'll be rejected from > the official archives if you keep it as-is. Ok, I've liked rspamc statically with that library and skip installing it during deb build. >> Acknowledged. So on upgrades of this package I should only inlcude lines >> like 'Update to version x.x.x', rigth? > Sure, 'initial release', 'new upstream release', 'fixed compilation on > 64 bit machines' or anything related to the packaging itself is OK. The > code related ones like 'added IPv6 support', 'many bugfixes', 'rework > events system' and 'write plugin for ...' are not. The latter ones can > go to toplevel_dir/ChangeLog with a date and version number added. I've fixed that as well. Thought FreeBSD port system is more tolerative in this aspect affording addition of the upstream changelog to a port's changelog, so why I thought that debian/changelog should be the same. -- Vsevolod Stakhov -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/501fb8ed.8010...@highsecure.ru
