Bugzilla – Bug 952799
bogofilter-{db,sqlite3} insists on using wordlist.tc
Last modified: 2022-09-06 16:29:57 UTC
In the past, when using other Linux distros I was mostly using bogofilter with sqlite3 back-end, but after switching to openSUSE I've decided to convert to 'default' (Berkeley) DB backend. Unfortunately, after bogofilter package was updated in openSUSE, it looks it does insist on using $HOME/.bogofilter/wordlist.tc for the database name even if one uses Berkeley DB or Sqlite3 back-ends? When I try to use my old wordlist.db, Bogofilter plugin (Claws & Evolution) starts from the scratch and creates wordlist.tc. I wonder about this line in *.spec: %if 0%{?suse_version} > 1320 iow. whether the new Bogofilter package is ready to use existing setup with appropriate back-end (not equal to TokyoCabinet)?
I just upgraded to tumbleweed from opensuse-13.2 bogofilter did not get installed as part of the upgrade, so installed bogofilter-db to match my existing database. Eventhough I selected the berkley db version, it insists that the db file be called wordlist.kct (for kyoto cabinet ?).
bogofilter-db vers 1.2.4 relase 9.4
On upgrading from Leap 43.2 to 15.0, bogofilter ignored the existing wordlist.db in directory .bogofilter, and started a new wordlist.kct. This in spite of running bogofilter-db (and not bogofilter-kyotocabinet, as the filetype might suggest). The effect of this is that bogofilter starts with a blank sheet, without any knowledge of what is spam and what is ham. The actual file format of the two is the same, so a workaround was to copy the wordlist.db to wordlist.kct (or rename if one doesn't want the original just in case).
@Saša, I believe the title should mention ".ktc" file, not ".tc" one. Anyway, I don't know how about -sqlite package, but -db one for sure ignores .db file and uses .ktc one. If someone already trained BF this work is simply lost (thus bumping it to "major" severity on the basis -- after years of usage program running from scratch is not "some loss of functionality under specific circumstances", it is complete loss). I checked two setups (many thanks for help Bogofilter community). With bogofilter-db I get the info about BF: bogofilter-kyotocabinet version 1.2.4 Database: Berkeley DB 4.8.30: (March 24, 2018) AUTO-XA wordlist r,word,/home/mist/.bogofilter/wordlist.kct,0 and with bogofilter-kct: bogofilter-kyotocabinet version 1.2.4 Database: Kyoto Cabinet 1.2.77 (TreeDB) wordlist r,word,/home/mist/.bogofilter/wordlist.kct,0 So both backends are hitting the same file. Leap 15.3.
Be sure to check * for configuration files in use, because those can tell bogofilter what database files to look for (and those won't differ between executable versions) * for what the alternatives package has actually set. bogofilter-db reporting as bogofilter-kyotocabinet looks fishy. You may want to trace with "which" and with looking at symlinks and tracing them, possibly with readlink or ls -l WITHOUT -H or -L options.
@Matthias, I don't know what configuration. I am posting this as a bug report against packaging. I just installed new Leap 15.3 plus I added bogofilter-db, as the result it states it is bogofilter-kyotocabinet, as I wrote previously. In case of program odd/wrong behaviour there could always be a issue with the setup or user interaction, but here it is clear case -- system installation + bogofilter-db. You cannot go more basic than that. I can run any command, no problem, but I would then ask what exactly should I run/check.
@Maciej, I posted relevant commands to print the configuration in use, and the default configuration, to the bogofilter list where this was also reported. If there is a configuration file in place, it may overwrite the location and/or name of the bogofilter data file! bogofilter -QQ bogofilter -QQ -C And also the manual page has a files section. We really need to establish a. what the packaging should be (I haven't found anything obviously wrong in the .spec file) and b. what your system actually provides. You also really need to trace the symlinks from the surmised executable through the update-alternatives maintained symlinks (with ls -l or namei or readlink or so). Without such information, that's hard to debug.
mist@localhost:~> bogofilter -QQ # bogofilter version 1.2.4 robx = 0.520000 # (5.20e-01) robs = 0.017800 # (1.78e-02) min_dev = 0.375000 # (3.75e-01) ham_cutoff = 0.450000 # (4.50e-01) spam_cutoff = 0.990000 # (9.90e-01) ns_esf = 1.000000 # (1.00e+00) sp_esf = 1.000000 # (1.00e+00) block-on-subnets = No encoding = utf-8 charset-default = iso-8859-1 replace-nonascii-characters = No no-header-tags = Yes stats-in-header = Yes report-unsure = No thresh-update = 0.000000 timestamp = Yes timestamp-date = 20211007 spam-header-name = X-Bogosity spam-header-place = '' spam-subject-tag = '' unsure-subject-tag = '' syslog-tag = '' header-format = %h: %c, tests=bogofilter, spamicity=%p, version=%v terse-format = %1.1c %f log-header-format = %h: %c, spamicity=%p, version=%v log-update-format = register-%r, %w words, %m messages spamicity-tags = Spam, Ham, Unsure spamicity-formats = %0.6f, %0.6f, %0.6f no-config-file = No config-file = '' user-config-file = ~/.bogofilter.cf bogofilter-dir = /home/mist/.bogofilter wordlist r,word,/home/mist/.bogofilter/wordlist.kct,0 db-cachesize = 4 ----------------------------------------------------------------- mist@localhost:~> bogofilter -QQ -C # bogofilter version 1.2.4 robx = 0.520000 # (5.20e-01) robs = 0.017800 # (1.78e-02) min_dev = 0.375000 # (3.75e-01) ham_cutoff = 0.450000 # (4.50e-01) spam_cutoff = 0.990000 # (9.90e-01) ns_esf = 1.000000 # (1.00e+00) sp_esf = 1.000000 # (1.00e+00) block-on-subnets = No encoding = utf-8 charset-default = iso-8859-1 replace-nonascii-characters = No no-header-tags = Yes stats-in-header = Yes report-unsure = No thresh-update = 0.000000 timestamp = Yes timestamp-date = 20211007 spam-header-name = X-Bogosity spam-header-place = '' spam-subject-tag = '' unsure-subject-tag = '' syslog-tag = '' header-format = %h: %c, tests=bogofilter, spamicity=%p, version=%v terse-format = %1.1c %f log-header-format = %h: %c, spamicity=%p, version=%v log-update-format = register-%r, %w words, %m messages spamicity-tags = Spam, Ham, Unsure spamicity-formats = %0.6f, %0.6f, %0.6f no-config-file = Yes config-file = '' user-config-file = ~/.bogofilter.cf bogofilter-dir = /home/mist/.bogofilter wordlist r,word,/home/mist/.bogofilter/wordlist.kct,0 db-cachesize = 4 ----------------------------------------------------------------- Remarks: there is no such file as "~/.bogofilter.cf". I don't want what I should execute for debug purposes, so I looked into "/usr/bin? -- all bogofilter symlinks are redirected to "/etc/alternatives" using the same name. "/etc/alternatives" bogofilter files are symlinked back to "/usr/bin" with "-db" suffixes. Btw. again, this is not "my" system as such, for testing purposes I simply installed (using VBox) Leap 15.3 and installed "bogofilter-db" package.
so, interpretation of @macias's findings: - the default setup on the system is the -db as established by the symlinks from /etc/alternatives - bogofilter -QQ -C printing something containing .kct is a non-default configuration, from an executable derived from a patched source. As upstream maintainer who is not an opensuse user, I'm out here and cannot help. I will unsubscribe from the bug.
Broken packages are still present in Leap 15.4. For the record, it is a regression, the correct packages were previously used.