The pipes from last time were probably allowing any webkitgtk version,
which isn't what we want. With this, we don't support old builds, but
we don't even try to support old builds anyway.
Having some trouble on Daily Build PPA, hopefully this will
allow a range of WebKitGTK libraries while still disallowing
version 2, which we don't build with.
More significant problem is that new symbol (from #6428) requires
GTK 3.6, so moved requirements up for it and Vala, plus couple
more than should've been updated a while back.
This is a limited implementation, so please backup your database before
running this search feature branch from now on as we may change things.
It's using a Unicode Snowball stemming tokenizer available from
https://github.com/littlesavage/sqlite3-unicodesn, also handily
available in src/sqlite3-unicodesn in Geary. If you want to look at the
search tables on the command line, cd into the unicodesn source folder,
run make and make install, then load sqlite3 like:
sqlite3 -cmd '.load unicodesn.sqlext' /path/to/geary.db
Adding '--parallel' to dh(1) calls permits parallel builds when
the user requests them, e.g. via the '-j' flag to dpkg-buildpackage
or other build helpers, or setting parallel=N in DEB_BUILD_OPTIONS
environment variable.
Previously I missed the quantal-specific control file, so our quantal
build didn't have messaging menu support. This bump will allow me to
cut another build that includes the right control file.
Will need to test this against a PPA, but I believe this fixes the
problem. gettext was not being initialized with the proper directory
because the PREFIX variable compiled into the binary was incorrect.
Prior attempt to use pipe operator in Build-Depend: list isn't
working, daily builds are failing for Quantal. Reverting back
to a control file that should work on both platforms, with the
Quantal-specific ready for release packaging.
Per a suggestion from Seb, this adds Messaging Menu as a hard
dependency for Geary, but if the build system doesn't find it, it
will fall back on libindicate. This means our packaging should
work for both Precise and Quantal.
Because Messaging Menu isn't available on Precise, a special
debian/control.quantal file is introduced here. We should move to
using it solely when we phase out Precise support.
It is done.
Initial implementation of the new database subsystem
These pieces represent the foundation for ticket #5034
Expanded transactions, added VersionedDatabase
Further expansions of the async code.
Moved async pool logic into Database, where it realistically
belongs.
Further improvements. Introduced geary-db-test.
Added SQL create and update files for Geary.Db
version-001 to version-003 are exact copies of the SQLHeavy scripts
to ensure no slight changes when migrating. version-004 upgrades
the database to remove the ImapFolderPropertiesTable and
ImapMessagePropertiesTable, now that the database code is pure
IMAP.
When we support other messaging systems (such as POP3), those
subsystems will need to code their own database layers OR rely on
the IMAP schema and simply ignore the IMAP-specific fields.
ImapDB.Account fleshed out
ImapDB.Folder is commented out, however. Need to port next.
ImapDB.Folder fleshed out
MessageTable, MessageLocationTable, and AttachementTable are now
handled inside ImapDB.Folder.
chmod -x imap-db-database.vala
OutboxEmailIdentifier/Properties -> SmtpOutboxEmailIdentifier/Properties
Moved SmtpOutboxFolderRoot into its own source file
SmtpOutboxFolder ported to new database code
Move Engine implementations to ImapDB.
Integration and cleanup of new database code with main source
This commit performs the final integration steps to move Geary
completely over to the new database model. This also cleans out
the old SQLHeavy-based code and fixes a handful of small bugs that
were detected during basic test runs.
Moved Outbox to ImapDB
As the Outbox is tied to the database that ImapDB runs, move the
Outbox code into that folder.
Outbox fixes and better parameter checking
Bumped Database thread pool count and made them exclusive
My reasoning is that there may be a need for a lot of threads at
once (when a big batch of commands comes in, especially at
startup). If performance looks ok, we might consider relaxing
this later.
