On September 21, 2015 6:29:20 PM EDT, "Mika Pflüger" <deb...@mikapflueger.de> wrote: > >Package: python-milter >Version: 1.0-1 >Severity: normal > >Hi, > >python-milter compilation seems to have been broken at some time during >the jessie cycle, and >since it hasn't been recompiled since then, it is still statically >compiled against libmilter >on most architectures. >See: >$ ldd /usr/lib/python2.7/dist-packages/milter.so > linux-vdso.so.1 (0x00007ffd87b9f000) >libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 >(0x00007efcf3d72000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007efcf39c9000) > /lib64/ld-linux-x86-64.so.2 (0x00007efcf41a9000) > >(There should be also a libmilter.so.1.0.1 in there) > >The problems are: >1. python-milter would not pick up security updates of libmilter. >2. python-milter actually _did not_ pick up the last changes in >libmilter, including the >socket activation patch added to make systemd socket activation >possible (that's how I found this). >So socket activation works if you write a C program using >smfi_setconn(), but does not work using >a python program with milter.setconn(). > >However, the build problem seems to have been fixed somehow already, if >I recompile in an up-to-date >sid, python-milter picks up the libmilter dependency just fine, so I >guess python-milter >only needs a binNMU to fix the binary packages in sid (and then >testing). > >I don't know if this warrants a fix in stable, it is quite annoying, >but is most likely not >a big problem (until there is a security hole in libmilter). If I >recompile in an up-to-date >stable chroot, it also picks up the dependency, so also in stable a >binNMU should fix it.
Don't ask for an unstable binNMU. There's some other things to do to improve the packaging, so I'll do an upload to get it rebuilt. Scott K
