Bug#683746: rspamd packaging
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
Reply to: