GNOME Bugzilla – Bug 584556
Add support for libgda5
Last modified: 2021-06-03 16:59:45 UTC
Currently only version 3 of libgda is supported. This version is rather old and even seems unmaintained by upstream developers. Some distributions only offer version 4.
Fedora 11 is one of the distros that uses libgda at version 4. Fedora offers libgda-4.0.2-1.fc11.i586 and libgda-postgres-4.0.2-1.fc11.i586. It is also available the package compat-libgda-3.1.2-2.fc11.i586 but there is no postgresql compat package. Due this there is no way of using PostgreSQL interaction using standard Fedora 11 packages. On Fedora 9, the libgda version is still 3. libgda-postgres-3.1.2-4.fc9.i386 libgda-3.1.2-4.fc9.i386
Foresight Linux is another distro that offers only version 4 of libgda.
I've just been informed by our Debian maintainer (Xavier Oswald) that they are switching to libgda4 too.
I've just been informed by Vincent Untz that we are the only reason openSUSE is keeping libgda3, so they're pretty interested in this too.
Starting with 10.10, Ubuntu only has libgda-4.0 and no libgda-3.0 anymore.
libgda5 is out, I changed the summary to take this into account. Also note that we'd better switch to GTK+ 3 before working on that.
This is still an issue, Ubuntu has dropped libgda3 and has to ship Planner without database support (tried Ubuntu 12.04 and 14.04). Moreover, I've installed libgda3 from Ubuntu 10.04 and I've tried to compile the master branch from git but I'm getting "/bin/sed: can't read /usr/lib/libgobject-2.0.la: No such file or directory"
Created attachment 305604 [details] [review] No package 'libgda-3.0' found. 10 patches to make planner connect to a PostgreSQL server.
Created attachment 305605 [details] [review] error: unknown type name 'GdaDict'. GdaDict The GdaDict object has been removed from Libgda.
Created attachment 305606 [details] [review] too few arguments to function 'gda_data_model_get_value_at'. https://developer.gnome.org/libgda/stable/GdaDataModel.html#gda-data-model-get-value-at
Created attachment 305607 [details] [review] too many arguments to function 'gda_init'. https://developer.gnome.org/libgda/stable/libgda-5.0-Libgda-Initialization.html#gda-init
Created attachment 305608 [details] [review] unknown type name 'GdaClient'.
Created attachment 305609 [details] [review] unknown type name 'GdaCommand'.
Created attachment 305610 [details] [review] unknown type name 'GdaDataSourceInfo'.
Created attachment 305611 [details] [review] implicit declaration of function 'gda_connection_get_database'.
Created attachment 305612 [details] [review] Do not throw the login when there is no password.
Created attachment 305613 [details] [review] Update the documentation. With this final patch, planner can connect to a PostgreSQL server. Read the user guide for more.
After applying all of these patches (via git bz apply), build phase failed with the following warning-errors: CC libstorage_sql_la-mrp-sql.lo mrp-sql.c: In function ‘sql_execute_command’: mrp-sql.c:249:9: error: format not a string literal and no format arguments [-Werror=format-security] g_warning (error->message); ^ mrp-sql.c: In function ‘sql_execute_query’: mrp-sql.c:276:9: error: format not a string literal and no format arguments [-Werror=format-security] g_warning (error->message); ^ mrp-sql.c: In function ‘sql_read_overriden_days’: mrp-sql.c:1140:16: error: variable ‘date’ set but not used [-Werror=unused-but-set-variable] mrptime date; ^ mrp-sql.c:1139:16: error: variable ‘day_type_id’ set but not used [-Werror=unused-but-set-variable] gint day_type_id; ^ mrp-sql.c: In function ‘dump_calendar_tree’: mrp-sql.c:1369:16: error: variable ‘data’ set but not used [-Werror=unused-but-set-variable] CalendarData *data; ^ mrp-sql.c: In function ‘sql_write_property_values’: mrp-sql.c:2783:45: error: variable ‘type’ set but not used [-Werror=unused-but-set-variable] const gchar *name, *label, *description, *type; ^ mrp-sql.c:2783:31: error: variable ‘description’ set but not used [-Werror=unused-but-set-variable] const gchar *name, *label, *description, *type; ^ mrp-sql.c:2783:23: error: variable ‘label’ set but not used [-Werror=unused-but-set-variable] const gchar *name, *label, *description, *type; ^ mrp-sql.c:2783:16: error: variable ‘name’ set but not used [-Werror=unused-but-set-variable] const gchar *name, *label, *description, *type; ^ cc1: all warnings being treated as errors make[2]: *** [Makefile:715: libstorage_sql_la-mrp-sql.lo] Error 1 make[2]: Leaving directory '/tmp/planner-d9d4377/libplanner' make[1]: *** [Makefile:493: all-recursive] Error 1 make[1]: Leaving directory '/tmp/planner-d9d4377' make: *** [Makefile:401: all] Error 2
"Warnings are errors" is legal... Try, ./configure --enable-compile-warnings=yes
Created attachment 351662 [details] nohup make And here's the result of configure Planner prefix : /nix/store/jljcpv5cn5vvlhk0blial09b0kzgnylf-planner-0.14.7 Build API docs : yes Python bindings : yes Python plugin : yes Simple priority scheduling : yes Database/GDA support : yes, 50 Evolution Data Server import : no Evolution Data Server backend: no
The point is that, yeah, they are. I can't sleep knowing there are unused variables...
Created attachment 351667 [details] [review] fix the "format-security" warning(s) in `g_warning` The printf's format string should always be present: at least "%s".
And, by the way, those "unused but set" variables aren't simply "unused": they are set later (via functions), but, well, their values aren't used anywhere. So they may be indeed a leftovers, and I need to simply clean them up (together with the respective code), or the previous patches removed something what they shouldn't -- that's not yet clear.
Created attachment 351671 [details] [review] error: variable set but not used There was two solutions: 1. Relax the "warnings are errors" rule in acinclude.m4. 2. Modify C sources. Apparently the second one is more popular. The patch is very conservative: It does not remove anything, it just clutter the code a little more.
(In reply to Ahmed Baïzid from comment #24) > Created attachment 351671 [details] [review] [review] > error: variable set but not used > > There was two solutions: ...or third, and the best: resolve the cause of those warnings. I just skimmed your patches and it doesn't appear like they are modifying anything here, so these issues existed before. But, nevertheless, the functions, in which the warnings are raised, look very strange and dirty... "overriden days" etc.
Review of attachment 351667 [details] [review]: I could not reproduce the "format-security" warnings. Nevertheless, the patch is a good one. https://developer.gnome.org/glib/stable/glib-Message-Logging.html#g-warning +1
Created attachment 351675 [details] [review] more comments and removals (where it's obvious)
Created attachment 351706 [details] [review] error: variable set but not used Planner considers warnings as errors and it use -Wunused option to compile. Thus, a construct like : #define d(x) is illegal. I've removed it and replaced its usage by g_warnings()/g_debug() calls. Defining variables without using them, is also illegal. I put unused variables in g_debug() calls. For src/planner-sql-plugin.c, the situation is simpler. I've just removed unused variables.
(In reply to Andrew Miloradovsky from comment #27) > Created attachment 351675 [details] [review] [review] > more comments and removals (where it's obvious) It seems you made planner work with database support. You have, probably, exported a project to a Postgresql server and imported it back. So what do you think of this feature ? Who is going to maintain the code (both C and SQL), maintain the documentation ? Not me. A database has to be maintained: backups, schema modifications. How many GNOME users are also RDMS managers ? Not me. Clearly, the database support is a toy. I will not investigate more. I'd better concentrate on Glade stuff, for instance.
Created attachment 351718 [details] git log screenshot it's not directly related to the subject, but it seems like konsole cannot render some symbols in your name properly, introduced in the last commit
Review of attachment 351706 [details] [review]: this patch overlaps with the previous one in mrp-sql.c
(In reply to Ahmed Baïzid from comment #29) > (In reply to Andrew Miloradovsky from comment #27) > > Created attachment 351675 [details] [review] [review] [review] > > more comments and removals (where it's obvious) > > It seems you made planner work with database support. > You have, probably, exported a project to a Postgresql server and imported > it back. I didn't do that actually, I don't have Postgres installed right now. > So what do you think of this feature ? Planner's data aren't that big so they have to be stored in a database. Storing the *.planner files in a (D)VCS (say, Git, Hg, or Darcs) is enough, but probably should be documented as a "tip". Either way, if I'd need to utilize a database, it would be a "NoSQL" DB, but not C code composing and parsing SQL queries and responses. > Who is going to maintain the code (both C and SQL), maintain the > documentation ? > Not me. Not me either. > A database has to be maintained: backups, schema modifications. How many > GNOME users are also RDMS managers ? > Not me. In theory, the choice of backend may be arbitrary and do not take any special efforts, say, XML and a DB schemas might be generated from a common description. But we aren't there at the moment. And, yes, that isn't worth it's efforts (because Planner files are small and are fine being stored in XML). > Clearly, the database support is a toy. > I will not investigate more. > I'd better concentrate on Glade stuff, for instance. I wouldn't mourn the *SQL support too, given what I've seen in the code: it's no longer actual, to say the least. But I'd like to have all the work committed, and only then cleaned up, so it stayed in the Git history, and not just here. Just in case.
Created attachment 351744 [details] [review] error: variable set but not used Corrected the author.
(In reply to Andrew Miloradovsky from comment #31) > Review of attachment 351706 [details] [review] [review]: > > this patch overlaps with the previous one in mrp-sql.c I did not understand. Which previous patch ? Mine ? Attachment 351744 [details] replaced attachment 351706 [details] [review] which replaced 351671. Yours ? Attachment attachment 351671 [details] [review] ? We were both working on src/planner-sql-plugin.c? We came to the same simple solution : delete. What is overlapping ? I applied the eleven patches. I had messages because I have not git-rebased since 2015. But the patches apply.
The modifications done in https://bugzilla.gnome.org/attachment.cgi?id=351744 to the file mrp-sql.c, Lines 246-252 and Lines 273-279 Are already present in https://bugzilla.gnome.org/attachment.cgi?id=351667 So if you try to apply them in series, the second will fail. (If the tool isn't smart enough to identify and correct re-application of patches/hunks.)
My tool is named the command line. I agree: it does not try to be smarter than me. $ for f in 00* ; do patch -p1 < $f ; done patching file configure.ac Hunk #1 succeeded at 80 (offset 1 line). Hunk #2 succeeded at 88 (offset 1 line). patching file libplanner/mrp-sql.c patching file libplanner/mrp-sql.c patching file src/planner-sql-plugin.c patching file libplanner/mrp-sql.c patching file src/planner-sql-plugin.c patching file libplanner/mrp-sql.c patching file src/planner-sql-plugin.c patching file libplanner/mrp-sql.c patching file src/planner-sql-plugin.c patching file libplanner/mrp-sql.c patching file src/planner-sql-plugin.c patching file src/planner-sql-plugin.c patching file libplanner/mrp-storage-sql.c patching file docs/sql/README.sql patching file docs/user-guide/C/planner.xml Hunk #1 succeeded at 2160 (offset -1 lines). Hunk #2 succeeded at 2177 (offset -1 lines). Hunk #3 succeeded at 2191 (offset -1 lines). Hunk #4 succeeded at 2210 (offset -1 lines). Hunk #5 succeeded at 2241 (offset -1 lines). Hunk #6 succeeded at 2277 (offset -1 lines). patching file libplanner/mrp-sql.c patching file src/planner-sql-plugin.c patching file libplanner/mrp-sql.c patching file src/planner-sql-plugin.c It is just that attachment 351744 [details] [review] is not in the list. We are both working on the same thing, there are some collisions...
Created attachment 351758 [details] [review] error: variable set but not used Take comment 35 into account.
These patches got collected into https://gitlab.gnome.org/World/planner/-/merge_requests/6 and then in turn into https://gitlab.gnome.org/World/planner/-/merge_requests/8 which is now merged. So we can consider this ticket as fixes, thanks for the patches!