... or at least local_scan.h:)
I'd like to write ebuilds for two libraries and both needs local_scan.h to be available.
 - http://dist.epipe.com/exim/
Hmmm, that shouldn't be too hard. Got a patch ready?
Created attachment 325172 [details, diff]
Patch for ebuild
I don't know how to install headers files using exim's build system so I did static list of headers files (dirty).
My proposal for change in metadata.xml is:
<flag name='dlfunc'>Adds support for using locally written C function</flag>
With proposed changes in ebuild I was able to build exim-geoipv6-dlfunc-0.1 and successfully use in expansion (tested via exim -be).
Created attachment 325176 [details, diff]
Patch for ebuild
I'm not so happy with the patch, because it includes config.h as shipped header. I presume the other headers include it as first-thing?
I used file list used by exim-dev on debian. And yes, local_scan.h needs config.h:
$ grep '#include' /usr/include/exim/*
I almost feel like it's saner to just add your two libraries to the main exim ebuild with two USE-flags.
For me it should be ok but enabling dlfunc is more general.
Hi Fabian, is any progress with this bug? Is something I can do to help resolving bug(s)?
I was thinking maybe it's best to add apply_user_patches or something to the exim ebuild, such that you can use this, as I'm not too happy adding this, since it exposes stuff that normally shouldn't be. Or the USE-flag idea, of course.
I'm admirer of system wide user_epatch. For me you can add it independent of this bug;)
I'm not programmer so it's not clear for me what is wrong with putting additional headers file to system? And I'm not sure it is good place for such discussion;)
Messems once main disadvantage of USE-flag is that the two dlfunc libraries are independent of upstream. Something like kernel and external modules like zfs;) or it can be treated as a kind of plugin. Hmm but nginx and NGINX_MODULES allows external modules to be compiled and installed together wit nginx.
I'm still thinking about using geoip and p0f inside exim;)
This is implemented now in 4.80.1-r1
Thanks Fabian for spending time on it! I emerged exim and I can see problem with installed headers:
ls -l /usr/include/exim/
-rw-r--r-- 1 root root 5695 07-22 23:17 config.h
-rw-r--r-- 1 root root 8201 07-22 23:17 local_scan.h
lrwxrwxrwx 1 root root 16 07-22 23:17 mytypes.h -> ../src/mytypes.h
lrwxrwxrwx 1 root root 14 07-22 23:17 store.h -> ../src/store.h
Last two are broken symlinks (while emerging I have QA Notices:
QA Notice: Symbolic link /usr/include/exim/mytypes.h points to /usr/include/src/mytypes.h which does not exist.
QA Notice: Symbolic link /usr/include/exim/store.h points to /usr/include/src/store.h which does not exist.
Thanks, I just fixed that (before I saw this bug). Yesterday, I didn't check too well what I did, I guess. The fix should propagate to the mirrors. I didn't bump because you're basically the only consumer now, so you'll have to re-emerge exim. Hope that's ok with you.
Now exim-p0f and exim-geoip builds fine. Thanks.
Now I'm going to use it on production MTA (about 1000-8000 emails per day). Would it be possible to add those ebuilds to tree after some time?
certainly yes, I hoped for you to test/check them first ;)
Thanks for commiting exim p0f and exim-geoip. Yes, I'm using both of them and (as for know) works without problem.