Update Notes cannot be displayed if PORTREVISION is set Not sure about the second fix to copy the sample files (firstrun.txt.sample ...) in a subdirectory 'txt' below $DSPAM_HOME (there is no hint for this exept in the sourcfile dspam.c). PS: drop the diff for the 'txt' subdirectory if this is expected How-To-Repeat: Install a fresh dspam instance, as user you expect to copy the files in /var/db/dspam/*.sampe and make changes there but if 'Notifications on' is set you will see the following error message in the logs - "Unable to open file for reading: firstrun.txt: No such file or directory"
Responsible Changed From-To: freebsd-ports-bugs->itetcu Over to maintainer (via the GNATS Auto Assign Tool)
Responsible Changed From-To: itetcu->ohauer ohauer is now a committer
Responsible Changed From-To: ohauer->itetcu Taek it back, I really care about this port, being on of hte upstream devels.
Unless itetcu takes it back again... back to pool as port is unmaintained and PR has not been handled for years.
Is this PR still relevant? If yes, please provide a new patch.
Yes, it is. Even I don't use the port I will do a rewrite since there are really some defects meanwhile. E.g. webui: ${INSTALL_DATA} -d /$path/to/$webui results in directories with mode 444 and you need root to create a package. ... I hope I have a rewrite at the end of the week, then we can also upgrade to 10.2 which is meanwhile stable since two years.
Thanks for clarifying. Let's wait for your new patch.
Will take my PR and do a rework of the port
Olli - I am attempting to come up with a patch to merge mail/dspam-devel in to mail/dspam (without clobbering any useful bits from either) and upgrade to 3.10.2 so that we can retire dspam-devel. The PRs for that are bug #177045 and bug #193693. What are your thoughts here? How is the rewrite going? Should we merge and update first and cleanup later? Or are you making fast progress on your rewrite and feel that would be the better way to get there? As far as your original bug goes, it looks like the two defects you mention appear to have been fixed at some point down the line.
Created attachment 147415 [details] dspam-cleanup-v1.diff
sorry for delay, I have a patch against dspam but haven't tested running functionality. It is a big cleanup but a good base for dspam-devel in case no new or changed configure args / options are between dspam/dspam-devel Danny, would you mind to look at the patch?
Ah some additional suggestion. Drop for e.g sqlite2, dovecot1 support. dovecot2 has so many improvements that no one should spend time with dovecot1, sqlite2 is used only used by six ports. After dropping sqlite2 PLIST_SUB can be cleaned even more.
Thanks for the patch, at glance all of this looks really good. I also agree with you about dropping dovecot1 and sqlite2. Though I can kinda see the need to hang on to dovecot1, just because of how closely related dovecot and dspam are. As long as someone is maintaining the dovecot1 and dovecot1-antispam ports then maybe we should probably keep the option around. But stale databases and other misc dependencies? Those should totally go. :) When I'm back to working on the big merge patch tonight I will figure out if it is easier to make your changes now or do it immediately after. I'm honestly not sure yet. The dspam and dspam-devel ports have been allowed to drift apart, but there are good features in both that I don't want to clobber.
Oh, and agreed that dovecot2 is awesome...
Olli, I pulled in some of your cleanup stuff in to the merge patch, see the latest attachment on bug #193693. I still haven't started on the bigger structural cleanup from your patch yet, though. It seems like the webui permissions issue is no longer happening, most likely due to the recent staging tweaks and permissions fixes from previous patches.
Bug #193693 has been committed, which brings mail/dspam up to date with the current upstream release (10.3.2) and merges dspam-devel in to dspam. See: https://svnweb.freebsd.org/ports?view=revision&revision=371290 https://svnweb.freebsd.org/ports?view=revision&revision=371291 A bunch of your fixes made it in to that patch, so thank you for that! We should probably close this bug out, as the original issue has been fixed. Olli does has some good points about the need to refactor this port, as it is doing way more footwork than it needs to for what should be a pretty straightforward port. I will create a new bug to cover any refactoring we need to do so we can track the progress of that, and refer back to Olli's notes from this bug.
*** This bug has been marked as a duplicate of bug 193693 ***