GNOME Bugzilla – Bug 777044
Move from cmake to meson build system
Last modified: 2018-06-13 12:43:43 UTC
Meson (http://mesonbuild.com/ and https://github.com/mesonbuild/meson/) starts to be adopted as the next Autotools build system for GNOME projects while cmake will probably never be. Thus it might be good to move to Meson but also for several other reasons: - it tends to replace autotools in the future - it is less verbose and easier to write/maintain than cmake scripts - it recompiles vala files **much** faster than cmake. Like 1 min for cmake vs 5 sec for meson when you touch an engine vala source file! Very useful when developing. I have started a branch for anyone wanting to play aound it: https://github.com/bagage/geary/tree/meson This branch is just compiling the bare minimum to have a running geary executable, but it can give you a rough idea of meson build.
Just FYI Meson 0.40 should have some nice vala-related improvements: https://mail.gnome.org/archives/vala-list/2017-April/msg00060.html
Created attachment 365348 [details] [review] [Patch] Port Geary to Meson Ported Geary to Meson. See the commit message for more details on the patch.
Review of attachment 365348 [details] [review]: Niels, nice work as always! I'll try it out when I have a spare moment, but after having a quick look I just wanted to check if there is a target for generating geary.pot (the old pot_file target that was recently resurrected) and what do you think we should do with the Makefile? Also, min meson version is set to 0.41, is there anything specific in the build that requires that and not, say 0.37?
Review of attachment 365348 [details] [review]: Err whoops, I mean "reviewed".
(In reply to Michael Gratton from comment #3) > Review of attachment 365348 [details] [review] [review]: > > Niels, nice work as always! Well, it's been way too long for a contribution from my side. But hey, I'm still alive and kicking \o/ > I'll try it out when I have a spare moment, but after having a quick look I > just wanted to check if there is a target for generating geary.pot (the old > pot_file target that was recently resurrected) and what do you think we > should do with the Makefile? The `i18n.gettext()` automatically provides a 'geary-pot' target [1]. I haven't completely followed the discussion, but I think it should suit your needs. > Also, min meson version is set to 0.41, is there anything specific in the > build that requires that and not, say 0.37? Well, technically you *could* go lower (to 0.39 IIRC, which enables `build_by_default` in custom targets), but version 0.41 is the lowest version to provide a `dist` target. [1] http://mesonbuild.com/i18n-module.html#i18ngettext
Review of attachment 365348 [details] [review]: Okay, sounds good. I was concerned that current Debian stable only shipped with 0.37, but they do have 0.42 in bpo, so that's probably good enough. It's probably best to commit to master, let people know on the mailing list and just start using it. Once that's baked for a few weeks we can rip out the CMake build.
Patch landed on master as commit 01c13f7. Mailing list announcement has also been sent (this bug is linked too).
Ta! I've just pushed a few fixes that get the build working for me locally, and fix a few issues running the app and tests from the source dir.
Two other regressions I noticed that I can't get to right away: - "-d" doesn't seem to work for some reason? - git branch and abbreviated commit id isn't appearing in version string
(In reply to Michael Gratton from comment #9) > - git branch and abbreviated commit id isn't appearing in version string Here's an example of how to do that: https://git.gnome.org/browse/epiphany/commit/?id=a12c3a602681f3a170b2d2376c55cba7633036c5 Of course, you'll have to disable shallow clones in your flatpak builder manifest, but that has nothing to do with meson: https://git.gnome.org/browse/epiphany/tree/org.gnome.Epiphany.json
Just a nitpick... When I build I see two missing dependencies, which are for Ubuntu only while I use Fedora: Dependency unity found: NO Library libmessaging-menu found: NO It would be nice if they were marked as Ubuntu dependencies or better not shown at all if meson seees that I'm not building on Ubuntu. Even better if they were not shown at all if the system does not have unity, as Ubuntu will go back to GNOME since next version 18.04.
(In reply to Michael Gratton from comment #9) > - "-d" doesn't seem to work for some reason? I'm not really sure what you mean, but maybe you should look into buildtypes [1] in Meson? Depending on the buildtype, Meson adds flags like `-d` to valac/gcc. About commit c25f254: I think you're mixing up preprocessor directives of C and Vala. The `configure_file()` only provides a file config.h which defines the C preprocessor directives (which is included with the `-include config.h` flag). This is not possible in Vala [2] and that's why we still need the `-D` Vala flags. (If you want, you *can* of course add them at the same place with `add_global_arguments(..., language: 'vala')`.) (In reply to Federico Bruni from comment #11) > It would be nice if they were marked as Ubuntu dependencies or better not > shown at all if meson seees that I'm not building on Ubuntu. > Even better if they were not shown at all if the system does not have unity, > as Ubuntu will go back to GNOME since next version 18.04. I get that it might be a bit weird at first to see huge red `NO`'s, but I'm afraid that's how Meson works. You actually can't check for libunity without either `YES` or `NO` showing up. The only other option I see here is possibly to add a Meson build option (adding another option to meson_options.txt). [1] http://mesonbuild.com/Running-Meson.html [2] https://wiki.gnome.org/Projects/Vala/Manual/Preprocessor
(In reply to Niels De Graef from comment #12) > (In reply to Michael Gratton from comment #9) > > - "-d" doesn't seem to work for some reason? > I'm not really sure what you mean, but maybe you should look into buildtypes > [1] in Meson? Depending on the buildtype, Meson adds flags like `-d` to > valac/gcc. Oh, no, in geary. Launching `geary --debug` doesn't produce the usual debug spew for me at the moment. > About commit c25f254: I think you're mixing up preprocessor directives of C > and Vala. The `configure_file()` only provides a file config.h which defines > the C preprocessor directives (which is included with the `-include > config.h` flag). This is not possible in Vala [2] and that's why we still > need the `-D` Vala flags. (If you want, you *can* of course add them at the > same place with `add_global_arguments(..., language: 'vala')`.) Ah, you're totally right. Thanks for pointing that out. I've reverted it and added a comment to remind future me. :) > I get that it might be a bit weird at first to see huge red `NO`'s, but I'm > afraid that's how Meson works. You actually can't check for libunity without > either `YES` or `NO` showing up. The only other option I see here is > possibly to add a Meson build option (adding another option to > meson_options.txt). Yeah, it would suck a bit, but I'd rather it be handled automatically rather than needing to be specifically enabled, or if an option is added it would be to disable the automatic check, but this seems like overkill tbh. Since they are optional and not fatal they should at least be printed yellow or something - maybe worth filing a Meson bug for?
Why these are owned by root? $ ls -l build/help/ totale 36 drwxr-xr-x 2 root root 4096 13 dic 07.17 cs drwxr-xr-x 2 root root 4096 13 dic 07.17 de drwxr-xr-x 2 root root 4096 13 dic 07.17 el drwxr-xr-x 2 root root 4096 13 dic 07.17 es drwxr-xr-x 2 root root 4096 13 dic 07.17 fr drwxr-xr-x 2 root root 4096 13 dic 07.17 it drwxr-xr-x 2 root root 4096 13 dic 07.17 pl drwxr-xr-x 2 root root 4096 13 dic 07.17 pt_BR drwxr-xr-x 2 root root 4096 13 dic 07.17 sv I noticed it while deleting build/ as normal user.
Created attachment 365532 [details] itstool crash Further to above, if I build and install in ~/.local, I get a itstool crash because of the permissions. See attached screenshot. When I click F1, no manual appears. The rest works fine.
Ney Niels, if you have a moment can you have a look at the last two commits on this branch: https://git.gnome.org/browse/geary/log/?h=wip/713611-conversation-message-delete and see if they seem sane from a Meson POV? They make the javascriptcore dependency able to be actually used as a build dep (using it was complaining of a missing header file otherwise) so engine and the engine tests don't need to depend on the full webkit library. The second splits the unit test build up into engine and client tests, and enables testing internal API from the engine. The former should be uncontroversial, but the latter does some heinous things in src/engine/meson.build to extract the internal API correctly. If you can think of a better way to achieve the same thing, do let me know.
(In reply to Federico Bruni from comment #14) > Why these are owned by root? > You probably did a ninja install as root, and currently meson generates docs when installing, not build time. Sound about right? I've opened a meson bug about this: https://github.com/mesonbuild/meson/issues/2775
Yes, I did a ninja install as root, in order to be able to install in /usr/local. meson build cd build ninja # help/ remains empty sudo ninja install # manuals are compiled and copied to the install directory
Another weird issue: selected text quoted in a reply does not work anymore only when using the binary built with meson. If I use the same git master version compiled with CMake, everything works correctly. Can you confirm it?
(In reply to Michael Gratton from comment #16) > Ney Niels, if you have a moment can you have a look at the last two commits > on this branch: > https://git.gnome.org/browse/geary/log/?h=wip/713611-conversation-message- > delete and see if they seem sane from a Meson POV? > > They make the javascriptcore dependency able to be actually used as a build > dep (using it was complaining of a missing header file otherwise) so engine > and the engine tests don't need to depend on the full webkit library. The > second splits the unit test build up into engine and client tests, and > enables testing internal API from the engine. > > The former should be uncontroversial, but the latter does some heinous > things in src/engine/meson.build to extract the internal API correctly. If > you can think of a better way to achieve the same thing, do let me know. Yes, it all looks good to me. (One disadvantage of Meson is that its user-friendliness can get in the way sometimes). For the copying of the internal VAPI and header file: one trick that I've seen elsewhere is to use `configure_file()` without a configuration parameter, which will just copy the file. That should put it in the correct directory, but it's still a bit hack-ish.
Created attachment 365647 [details] [review] [Patch] Configure script for Meson Attachment takes the configure file and makes it applicable to Meson. Note that there is no 1-to-1 mapping of the old configure script's options.
(In reply to Niels De Graef from comment #20) > > Yes, it all looks good to me. (One disadvantage of Meson is that its > user-friendliness can get in the way sometimes). For the copying of the > internal VAPI and header file: one trick that I've seen elsewhere is to use > `configure_file()` without a configuration parameter, which will just copy > the file. That should put it in the correct directory, but it's still a bit > hack-ish. Cool, thanks. I've pushed as-is since it's been tested and I can't bear the thought of revisiting that hack at the moment, but the configure_file trick is good to know. :) I've also pushed some logging cleanup that includes a fixes -d not working under Meson. Turns out we needed to set a default logging handler, which wasn't done previously.
Hey Federico, (In reply to Federico Bruni from comment #18) > Yes, I did a ninja install as root, in order to be able to install in > /usr/local. > > meson build > cd build > ninja # help/ remains empty > sudo ninja install # manuals are compiled and copied to the install directory Oh, so does this mean you get a translated manual show up okay after doing a ninja install? If so, do you have a packaged (deb/rpm/flatpak) version installed as well? (In reply to Federico Bruni from comment #19) > Another weird issue: selected text quoted in a reply does not work anymore > only when using the binary built with meson. If I use the same git master > version compiled with CMake, everything works correctly. > > Can you confirm it? Yeah, confirmed. I've noticed it as well.
Fedora package is not installed. I've uninstalled the flatpak installation. I've cleaned a previous installation made with CMake and started a fresh compilation. It cannot find the translated manual. yelp says something like: "`ghelp:geary` URI does not point to a valid page". The files are copied in the correct directories, so there's something else preventing it from working. $ ls /usr/local/share/help/it/geary/ accounts.page bugs.page label.page overview.page search.page star.page archive.page index.page limits.page preferences.page shortcuts.page write.page By the way, ninja gives these warnings: $ ninja [11/468] Generating webkit2gtk-4.8.vapi with a custom command. WebKit2-4.0.gir:6102.7-6102.17: warning: Signal `WebKit.PrintCustomWidget.apply' conflicts with method of the same name WebKit2-4.0.gir:6116.7-6116.19: warning: Signal `WebKit.PrintCustomWidget.update' conflicts with method of the same name WebKit2-4.0.gir:10686.7-10686.77: warning: Virtual method `WebKit.WebContext.initialize_notification_permissions' conflicts with method of the same name WebKit2-4.0.gir:11001.7-11003.22: warning: Signal `WebKit.WebContext.initialize_notification_permissions' conflicts with method of the same name [468/468] Linking target test/geary-test-client.
This works fine: $ yelp /usr/local/share/help/it/geary/index.page Same if I launch yelp and then I see the list of all help manuals (click on menu and then Help). So it doesn't work only when the user manual is called from Geary. If I launch Geary in english (LANG=C geary), user manual is not found. Here's the exact english error message: Document Not Found The URI ‘ghelp:geary’ does not point to a valid page. Here's something useful. This works but launches the english manual despite LANG=it_IT: $ yelp help:geary This does not work: $ LANG=it yelp help:geary (yelp:11306): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
I found another problem with the meson build: linked images in the body message are shown by default without asking confirmation for loading (once or always for this contact).
I think I'm pretty happy with where this is at. Michael: Thanks for the git version pointer, I went with a combination of Ephy's approach and Meson's vcs_tag() in the end. Niels: Thanks for the patch, but I was thinking more about the Makefile. I've pushed some tweaks for that and just removed the two configure files. Federico: I've made some changes to how the user manual is getting built and invoked: - When using Meson <= 0.44, non-C locale translations should now be getting correctly installed - Since Meson's help support installs to /usr[/local]/share/help, not ../share/gnome/help, we need to use the "help" URI, not "ghelp". Please try it out after updating master and installing with Meson using "yelp help:geary" instead. That seems to have broken help in Flatpak though. O_o I've also enabled warning output and fixed as many as I had the head space for. Also, I can't reproduce the issue with images being unintentionally automatically loaded - that feature seems to be working fine for me.
I've just built master using `make && sudo make install`. I have meson 0.44.0 installed. I cannot reproduce the issue with images being unintentionally automatically loaded either. The user manual is found correctly and displayed in my language either when I press F1 in Geary and when I run `yelp help:geary`. Select quoted text and reply doesn't work yet, unfortunately.
Another problem I'm having, don't know if it's related to meson build or not, is that I cannot add a new account anymore. In the log I see this: [deb] 06:28:58 0,209280 geary: geary-controller.vala:811: Successfully validated account information [deb] 06:28:58 0,040351 geary: db-versioned-database.vala:77: VersionedDatabase.upgrade: current database schema for /home/fede/.local/share/geary/account_02/geary.db: 11 [deb] 06:28:58 0,000037 geary: db-versioned-database.vala:126: Upgrading database to version 12 with /usr/local/share/geary/sql/version-012.sql [deb] 06:28:58 0,012450 geary: db-versioned-database.vala:126: Upgrading database to version 13 with /usr/local/share/geary/sql/version-013.sql [deb] 06:28:58 0,011915 geary: db-connection.vala:397: Connection.exec_transaction: transaction threw error: (Connection.exec /home/fede/.local/share/geary/account_02/geary.db) [err=1] - no such table: MessageSearchTable (DELETE FROM MessageSearchTable) [deb] 06:28:58 0,000011 geary: imap-db-database.vala:362: Error populating old inline attachments during upgrade to database schGtk-Message: GtkDialog mapped without a transient parent. This is discouraged. The dialog says something like (translating from italian): Could not open the local mailbox for account_02 An error occurred while opening the local account, probably because of connectivity problems. Check the network settings and restart the application.
I forgot to add that `geary --version` and the About window both show "geary 0.13-dev". No git committish.
Federico, are you sure you have built latest master, or are running the correct binary? This is what I see in my current working directory: > mjg@payens:~/Projects/GNOME/geary$ ./build/src/geary --version > geary master~g63df0233-dirty Also, I can only sometimes reproduce the reply-quote issue, I think it might be a race or similar caused by some underlying bug that Meson's build flags makes more likely to happen. (In reply to Federico Bruni from comment #29) > Could not open the local mailbox for account_02 > An error occurred while opening the local account, probably because of > connectivity problems. > Check the network settings and restart the application. That's a little bit disconcerting, did that account work fine after a restart?
I'm pretty sure I'm building latest master. And `which -a geary` shows only one binary (in /usr/local). Perhaps you have a different version of Meson? I'll try again from scratch. BTW, these files are still owned by root so `make distclean` cannot remove them and I have to use `sudo rm`: [geary (master=)]$ ls -l build/help/ total 36 drwxr-xr-x 2 root root 4096 Jan 16 06:03 cs drwxr-xr-x 2 root root 4096 Jan 16 06:03 de drwxr-xr-x 2 root root 4096 Jan 16 06:03 el drwxr-xr-x 2 root root 4096 Jan 16 06:03 es drwxr-xr-x 2 root root 4096 Jan 16 06:03 fr drwxr-xr-x 2 root root 4096 Jan 16 06:03 it drwxr-xr-x 2 root root 4096 Jan 16 06:03 pl drwxr-xr-x 2 root root 4096 Jan 16 06:03 pt_BR drwxr-xr-x 2 root root 4096 Jan 16 06:03 sv Also, make distclean does not remove the binaries created in the project root, that is: [geary (master=)]$ ls -l geary* -rwxrwxr-x 1 fede fede 15687016 Jan 15 21:33 geary -rwxrwxr-x 1 fede fede 3632504 Jan 15 21:33 geary-console -rwxrwxr-x 1 fede fede 1935056 Jan 15 21:33 geary-mailer
I've rebuilt from scratch, but I still have the same issue with --version: [geary (master=)]$ ./build/src/geary --version geary 0.13-dev [geary (master=)]$ ./geary --version geary 0.13-dev
Created attachment 366985 [details] core dump > (In reply to Federico Bruni from comment #29) > > Could not open the local mailbox for account_02 > > An error occurred while opening the local account, probably because of > > connectivity problems. > > Check the network settings and restart the application. > > That's a little bit disconcerting, did that account work fine after a > restart? No, it didn't and Geary became unusable until I manally deleted the account_02 folders in ~/.config and ~/.local. I've just tried adding a Gmail account and it crashed with this error: [deb] 06:40:13 0,006634 geary: imap-db-database.vala:230: Creating search table using italian stemmer ![???] 06:40:13 0,001152 geary: imap-db-database.vala:249: Error creating search table: (Connection.exec /home/fede/.local/share/geary/account_02/geary.db) [err=1] - unknown tokenizer: unicodesn ( CREATE VIRTUAL TABLE MessageSearchTable USING fts4( body, attachment, subject, from_field, receivers, cc, bcc, tokenize=unicodesn "stemmer=italian", prefix="2,4,6,8,10", ); ) Trace/breakpoint trap (core dump creato) See attached file.
I've just tried launching Geary with `LANG=C geary -d` to see if it was a problem with locale. But even in english I get the crash: [deb] 07:45:35 0.220051 geary: geary-controller.vala:811: Successfully validated account information [deb] 07:45:35 0.014742 geary: db-versioned-database.vala:77: VersionedDatabase.upgrade: current database schema for /home/fede/.local/share/geary/account_02/geary.db: 0 [deb] 07:45:35 0.000073 geary: db-versioned-database.vala:126: Upgrading database to version 1 with /usr/local/share/geary/sql/version-001.sql [deb] 07:45:35 0.030499 geary: db-versioned-database.vala:126: Upgrading database to version 2 with /usr/local/share/geary/sql/version-002.sql [deb] 07:45:35 0.020587 geary: db-versioned-database.vala:126: Upgrading database to version 3 with /usr/local/share/geary/sql/version-003.sql [deb] 07:45:35 0.028735 geary: db-versioned-database.vala:126: Upgrading database to version 4 with /usr/local/share/geary/sql/version-004.sql [deb] 07:45:35 0.016897 geary: db-versioned-database.vala:126: Upgrading database to version 5 with /usr/local/share/geary/sql/version-005.sql [deb] 07:45:35 0.018634 geary: db-versioned-database.vala:126: Upgrading database to version 6 with /usr/local/share/geary/sql/version-006.sql [deb] 07:45:35 0.016494 geary: db-versioned-database.vala:126: Upgrading database to version 7 with /usr/local/share/geary/sql/version-007.sql [deb] 07:45:35 0.013111 geary: db-versioned-database.vala:126: Upgrading database to version 8 with /usr/local/share/geary/sql/version-008.sql [deb] 07:45:35 0.013793 geary: db-versioned-database.vala:126: Upgrading database to version 9 with /usr/local/share/geary/sql/version-009.sql [deb] 07:45:35 0.015250 geary: db-versioned-database.vala:126: Upgrading database to version 10 with /usr/local/share/geary/sql/version-010.sql [deb] 07:45:35 0.020562 geary: db-versioned-database.vala:126: Upgrading database to version 11 with /usr/local/share/geary/sql/version-011.sql [deb] 07:45:35 0.013507 geary: imap-db-database.vala:230: Creating search table using english stemmer ![???] 07:45:35 0.000616 geary: imap-db-database.vala:249: Error creating search table: (Connection.exec /home/fede/.local/share/geary/account_02/geary.db) [err=1] - unknown tokenizer: unicodesn ( CREATE VIRTUAL TABLE MessageSearchTable USING fts4( body, attachment, subject, from_field, receivers, cc, bcc, tokenize=unicodesn "stemmer=english", prefix="2,4,6,8,10", ); ) Trace/breakpoint trap (core dump creato) It's something about my sqlite3 installation? I'm using sqlite version 3.20.1 from Fedora 27 repository.
(In reply to Michael Gratton from comment #31) > Federico, are you sure you have built latest master, or are running the > correct binary? This is what I see in my current working directory: > > > mjg@payens:~/Projects/GNOME/geary$ ./build/src/geary --version > > geary master~g63df0233-dirty > dirty? I can't find that committish in master... I'm currently at cc29024501f492fcb14b64e707e08a934c7bf05b > Also, I can only sometimes reproduce the reply-quote issue, I think it might > be a race or similar caused by some underlying bug that Meson's build flags > makes more likely to happen. I can reproduce it always.
(In reply to Federico Bruni from comment #34) > No, it didn't and Geary became unusable until I manally deleted the > account_02 folders in ~/.config and ~/.local. > > I've just tried adding a Gmail account and it crashed with this error: > > [deb] 06:40:13 0,006634 geary: imap-db-database.vala:230: Creating search > table using italian stemmer > ![???] 06:40:13 0,001152 geary: imap-db-database.vala:249: Error creating > search table: (Connection.exec That is pretty bad. Does the same thing happen using the CMake build? Either way, what about if you check out a commit before a0ff57c, e.g. commit cbfb7d5 or commit 37c218d and build from that?
commit cbfb7d5: same error commit 37c218d: I used Cmake and account creation works fine
I just pushed commit eebe498 which should actually fix the git version issue. (In reply to Federico Bruni from comment #38) > commit cbfb7d5: same error > > commit 37c218d: I used Cmake and account creation works fine So it looks like the meson build just isn't building or linking Geary's custom tokeniser on your system properly. Can you please update to current master, remove your build dir, configure and run a full build, and attach the complete log here? "rm -rf build && make |& tee geary-build.txt" or similar would be good. Also, what do you get as the output for "ldd build/src/geary | grep sql"? (In reply to Federico Bruni from comment #36) > dirty? That shows up if there's any un-committed changes in the current working directory. My working tree is usually pretty messy. :)
Created attachment 367460 [details] build log This is what I get before cleaning and pulling the latest commits in master: $ ldd build/src/geary | grep sql libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007f2aa68cd000) I've cleaned and rebuild latest master. See attached log. The output is almost identical: $ ldd build/src/geary | grep sql libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007f200e831000) git version now works fine: $ ./build/src/geary --version geary master~g0c837d31 Issues still open: - Files and directories under build/help are still owned by root. - Account creation still causes a segfault. I can attach the dump caught by systemd-coredump if you need it.
Another thing I've noticed is that after making a change to the engine, I need to run ninja twice to get it to rebuild the geary binary. Federico, I'm not really sure what the issue is with SQLite. The only other thing I can think of is maybe it's a difference between installed versions of some package (meson maybe?) on your system vs mine, since you have more recent versions of a bunch of things. Will try at least Meson 0.44 and see if I can reproduce the issue.
I'm now using Meson 0.44.1 (I've just posted an error on the mailing list). I've recently noticed another problem: when I select some text, either in the composer or the vewer, and I right-click, I cannot click on Copy (it appears disabled). Only Ctrl-C is working. This happens on version master~g0c837d31. I will double check on recent master as soon as I'm able to build it again.
Federico, has account creation ever worked for you with the meson build? If you go all te way back to the commit which added support for meson (e.g commit 01c13f72), build that and try adding an account, does it work? If it does work, then doing a git bisect to work out which commit introduced the problem would be really handy. Also, you're on Fedora, is that right? Which version?
I'm on Fedora 27. I've just created a new user, in order to test it without messing up with my working configuration (as I have only one account in Geary at the moment). I tried to add a new account (type other) and I got a crash. It seems related to localization and sql? I think I've already seen this error but cannot remember in which situations. Here's what I see in Fedora bug report application: User Logs: --mar 26 10:31:21 federico geary[9842]: GtkDialog mapped without a transient parent. This is discouraged. mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: ![???] 10:32:33 72,054022 geary: imap-db-database.vala:249: Error creating search table: (Connection.exec /home/test/.local/share/geary/account_01/geary.db) [err=1] - unknown tokenizer: unicodesn ( mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: CREATE VIRTUAL TABLE MessageSearchTable USING fts4( mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: body, mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: attachment, mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: subject, mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: from_field, mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: receivers, mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: cc, mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: bcc, mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: tokenize=unicodesn "stemmer=italian", mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: prefix="2,4,6,8,10", mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: ); mar 26 10:32:33 federico org.gnome.Geary.desktop[9842]: )
Created attachment 370140 [details] core dump
Mike, it seems related to these issues: https://bugzilla.redhat.com/show_bug.cgi?id=1337903 https://github.com/pimvullers/elementary/issues/152
Account creation works fine when I use commit 01c13f72. My sqlite version is 3.20.1. Let me know if you need any other information.
Quite a nasty bug.. I tried to checkout 01c13f72 to be able to add an account. When I run `meson build` I see: Header <sqlite3.h> has symbol "SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER": YES I guess we need something similar for fts4? Anyway, using that old checkout, I have this problem: ``` $ geary -d geary: error while loading shared libraries: libgeary-client.so: cannot open shared object file: No such file or directory ``` Here's the log printed in the terminal when running `geary -d` using current master: ``` [deb] 13:14:12 0,074594 geary: db-versioned-database.vala:126: Upgrading database to version 11 with /usr/local/share/geary/sql/version-011.sql [deb] 13:14:12 0,049877 geary: imap-db-database.vala:230: Creating search table using italian stemmer ![???] 13:14:12 0,000499 geary: imap-db-database.vala:249: Error creating search table: (Connection.exec /home/fede/.local/share/geary/account_01/geary.db) [err=1] - unknown tokenizer: unicodesn ( CREATE VIRTUAL TABLE MessageSearchTable USING fts4( body, attachment, subject, from_field, receivers, cc, bcc, tokenize=unicodesn "stemmer=italian", prefix="2,4,6,8,10", ); ) Trace/breakpoint trap (core dump creato) ```
Federico, I'm going to pull the CMake build out soon since it's too much work to maintain both. Would it be possible for you to jump on the IRC channel sometime so we can work out what the problem with your meson build is? It might be a lot faster than doing it here or via email.
Hey Federico, I finally managed to reproduce the SQLite problem you were seeing, and landed a fix for it in https://gitlab.gnome.org/GNOME/geary/merge_requests/5. So the meson build really, really should be working for you now. (PS: Apologies for disappearing off IRC, I was off hiking for a couple of day then got called overseas unexpectedly) I'll rip the CMake build out over the next few days once Bug 782854 lands either way and finally resolve this as fixed.
Hey Mike, I confirm I can now add a new account again. Thanks!
Good to hear! CMake build has just been removed by commit 98e2d319. May it remain long in our commit histories.