- Dec 12, 2018
-
-
Debarshi Ray authored
-
-
- Dec 05, 2018
-
-
Debarshi Ray authored
-
Debarshi Ray authored
-
Debarshi Ray authored
-
- Nov 28, 2018
-
-
Carmen Bianca BAKKER authored
(cherry picked from commit 2bc35ff2)
-
- Nov 27, 2018
-
-
Debarshi Ray authored
-
Debarshi Ray authored
-
Debarshi Ray authored
-
Debarshi Ray authored
A GCancellable can be cancelled from a different thread than the one where the GTask for the goa_http_client_check operation was created. Since the GCancellable::cancelled handler is invoked in the same thread as the g_cancellable_cancel call, unguarded access to the GError in CheckData is unsafe. Instead of introducing a GMutex, the GError can be set in the response callback which is guaranteed to be invoked in the same thread where the GTask was created. Ensuring that the GError is always accessed from the same thread makes it considerably easier to reason about its state. eg., it can be guaranteed that it won't be set if the status of the response isn't SOUP_STATUS_CANCELLED.
-
Debarshi Ray authored
The synchronous variant of goa_http_client_check runs a thread-specific GMainContext until the asynchronous variant invokes its callback. Once the callback is invoked, the GMainLoop is quit. This means that there won't be any further iterations of the loop and no new GSources will be dispatched. Therefore, when the synchronous HttpClient gets aborted by the GCancellable or due to an SSL error, then the following http_client_check_response_cb might not be invoked due to the lack of a running GMainLoop to drive the GMainContext; as a result, the GTask will get leaked. Solve this by tracking the GError and returning the GTask only when everything is complete. This was fixed in commit 3b35bd71, but broke in commit 73242fa2 when porting to GTask. https://bugzilla.gnome.org/show_bug.cgi?id=764157
-
Debarshi Ray authored
Now that the deprecated SoupSessionAsync has been replaced with SoupSession [1], the response callbacks are invoked in the next iteration of the main loop after soup_session_abort has returned. This means that ews_client_autodiscover_response_cb is no longer called from a GCancellable::cancelled signal handler. Therefore, it's safe to directly disconnect from the GCancellable in the response callback without fearing for any deadlocks. This reverts commit 07f13b1d. [1] Commit 6c3e3c2d https://bugzilla.gnome.org/show_bug.cgi?id=764157
-
Debarshi Ray authored
Now that the deprecated SoupSessionAsync has been replaced with SoupSession [1], the response callbacks are invoked in the next iteration of the main loop after soup_session_abort has returned. This means that http_client_check_response_cb is no longer called from a GCancellable::cancelled signal handler. Therefore, it's safe to directly disconnect from the GCancellable in the response callback without fearing for any deadlocks. This reverts commit b2f94098. [1] Commit 6c3e3c2d https://bugzilla.gnome.org/show_bug.cgi?id=764157
-
- Nov 26, 2018
-
-
Andrea Veri authored
-
Andrea Veri authored
-
- Nov 23, 2018
-
-
Debarshi Ray authored
-
Debarshi Ray authored
-
Debarshi Ray authored
During the GNOME 3.25.x / 3.26 development cycle it was decided that Todoist doesn't fit the goals of GNOME Online Accounts [1]. The two applications that were meant to consume the Todoist provider, GNOME Recipes [2] and To Do [3], are not part of a minimum viable GNOME system. While they do bear the GNOME name and follow the GNOME Human Interface Guidelines [4], they are not tightly coupled with the rest of GNOME. eg., they don't follow the GNOME development and release schedule. They are optional applications which often won't be installed, and we don't want to have online accounts that don't do anything. Since then, Recipes has grown its own built-in Todoist support, and To Do is expected to do the same. [1] https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals [2] https://wiki.gnome.org/Apps/Recipes [3] https://wiki.gnome.org/Apps/Todo [4] https://developer.gnome.org/hig/stable/
-
- Oct 28, 2018
-
-
Anish Sheela authored
(cherry picked from commit a21c5362)
-
- Oct 16, 2018
-
-
Kristjan SCHMIDT authored
-
- Oct 03, 2018
-
-
Debarshi Ray authored
These two pre-processor macros have existed since the first commit, but it isn't clear why. They were used with the Settings panel while it lived in gnome-online-accounts.git, but were dropped when it was moved to gnome-control-center.git [1], again, it isn't clear why. The _POSIX_PTHREAD_SEMANTICS documentation [2] says that it will "enable threading extensions on Solaris", and is covered under the AC_USE_SYSTEM_EXTENSIONS banner. The code in gnome-online-accounts.git uses threads, but does so via the GLib and GIO APIs, and doesn't use the POSIX threads (or pthreads) API directly. GLib itself defines it as part of AC_USE_SYSTEM_EXTENSIONS in its Autotools build [3] but not in the Meson build. The Meson build does define other AC_USE_SYSTEM_EXTENSIONS components, but not _POSIX_PTHREAD_SEMANTICS. Therefore, it seems safe to conclude that the _POSIX_PTHREAD_SEMANTICS doesn't serve any purpose here in gnome-online-accounts.git. The _REENTRANT documentation [4] says that it's obsolete. GLib defines it on Solaris and Mac OS X in its Autotools build, but that's solely for the Oracle compilers on Solaris and possibly other historical reasons. Both GCC and Clang appear to expand -pthread to define _REENTRANT on their own [5]. Since Meson doesn't support the Oracle compiler, it's not present in GLib's Meson build at all [6]. Given the current momentum towards Meson in GNOME, and that Meson doesn't support it, it's safe to ignore anything specific to the Oracle compiler. Hence _REENTRANT can be removed. [1] https://bugzilla.gnome.org/show_bug.cgi?id=653334 https://bugzilla.gnome.org/show_bug.cgi?id=653335 [2] https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Posix-Variants.html [3] https://bugzilla.gnome.org/show_bug.cgi?id=684123 [4] https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html [5] https://stackoverflow.com/questions/875789/do-i-need-d-reentrant-with-pthreads https://github.com/mesonbuild/meson/issues/3810 [6] https://gitlab.gnome.org/GNOME/glib/issues/1432 https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/14
-
- Oct 01, 2018
-
-
Debarshi Ray authored
Fallout from d46cd37f
-
- Sep 05, 2018
-
-
Yuras Shumovich authored
(cherry picked from commit c1fa585b)
-
- Sep 01, 2018
-
-
Madis O authored
-
Debarshi Ray authored
-
Debarshi Ray authored
-
- Aug 20, 2018
-
-
Khaled Hosny authored
-
- Aug 16, 2018
-
-
Debarshi Ray authored
-
Debarshi Ray authored
-
Debarshi Ray authored
Building with AX_CHECK_ENABLE_DEBUG([yes]), which is what happens by default for non-release builds, turns off compiler optimizations and overrides any optimization specified via CFLAGS in the build environment. This means that the nightly Flatpaks, and almost all other non-release builds, are built without any optimization. This triggers a warning about _FORTIFY_SOURCE requiring optimization, on distributions that build with _FORTIFY_SOURCE, when running g-ir-scanner to generate Goa-1.0.gir. Since g-ir-scanner uses Python's distutils.ccompiler, the compiler flags with which Python itself was built gets tagged into the compilation of the generated code that's used to generate the GIR. If the Python installation being used was built with _FORTIFY_SOURCE, the warning is triggered. It can be useful to turn off compiler optimizations to get a better debugging experience, but it becomes a problem if it stomps over the build environment while doing so. The person doing the builds should should get to decide between ease of debugging and other factors. After all, debugging is not the only thing that a developer does. One can use GDB reasonably well with the Autoconf default, which also happens to be what most distributions use, of "-g O2". This wouldn't have been such a problem if AX_CHECK_ENABLE_DEBUG attached its flags before the values from the environment instead of after, because in case of multiple -O options, the last such option is the one that's effective. Thankfully, "no" doesn't override the environment, which is what happens for release builds, and distributions generally set their own CFLAGS. Otherwise every single user-facing build would have been broken. Note that any release build without CFLAGS set in the environment would neither get debug symbols (ie., no "-g") nor any compiler optimization because AX_CHECK_ENABLE_DEBUG always suppresses the Autoconf defaults of "-g -O2". One solution could have been to default to "info" for non-release builds and recommend the use of --enable-debug=info while building from Git, but that would not address release builds without CFLAGS. Given that the only other thing the macro does is to define the NDEBUG pre-processor macro when debugging is set to "no", which isn't widely used in the GLib-based GNOME platform [1], it seems better to just remove it altogether. [1] glib/gio/xdgmime is the only widely used code path where assert(3) is used. It's also used in gio/kqueue/dep-list.c, which is *BSD-specific and in GTK+'s Broadway backend. All those can probably be replaced with g_assert*. https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/10
-
Debarshi Ray authored
GCC 8 introduced -Wcast-function-type. It is enabled by -Wextra, which is on the AX_COMPILER_FLAGS list. Unfortunately, this cannot be sanely used with the GNOME platform. It is exceedingly common practice to specify a function as a callback that ignores some of the trailing parameters passed to it. In fact, the following snippet that's part of the g_list_copy_deep documentation triggers -Wcast-function-type: another_list = g_list_copy_deep (list, (GCopyFunc) g_object_ref, NULL); Disabling warnings like this does go against the recommendation of the AX_COMPILER_FLAGS documentation, which suggests the use of #pragmas instead. However, unlike passing the flags through the command line, attempts to ignore -Wcast-function-type through a #pragma will trigger -Wpragmas on older versions of GCC, and, ironically, using G_GNUC_CHECK_VERSION to conditionally disable it on newer compilers will trigger -Wexpansion-to-defined, again, because of -Wextra.
-
- Jul 20, 2018
-
-
Iñigo Martínez authored
Although #FooObject style links are properly created from the source code, there are two content files, `goa-daemon.xml` and `goa-overview.xml`, that should also be expanded to generate links from tokens. https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/2
-
Iñigo Martínez authored
Meson's configuration object `set` method receives a boolean value. On the other hand, there are a set of options related to the type of accounts supported by `gnome-online-accounts`. These options can be used as the boolean parameter directly in the `set` method, so there is no need to use a conditional statements. https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/2
-
Iñigo Martínez authored
Following autotools build files, the project name was set to `GNOME Online Accounts`, so a variable was created to be used as package datadir and gettext domain set to `gnome-online-accounts` string. However, recently the project name has been changed to `gnome-online-accounts` so the variable used as package datadir and gettext domain is not necessary anymore. https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/2
-
Debarshi Ray authored
-
Iñigo Martínez authored
The `HAVE_TIMERFD` define should only be set when the test code compiles. When the code compiles we can ensure that `HAVE_TIMERFD` has to be unconditionally defined, so the auxiliary `have_timerfd` variable used for this is unnecessary. https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/2
-
- Jul 19, 2018
-
-
-
Emmanuele Bassi authored
Build against GLib 2.57.2 See merge request GNOME/gnome-online-accounts!8
-
Emmanuele Bassi authored
The g_clear_pointer() macro in GLib gained a bit of type safety when using GCC and GCC-compatible compilers; now, though, GCC really does not like it when people cast the destroy argument to GDestroyNotify. The macro was added precisely to avoid the need to cast the arguments for g_clear_pointer(), so the cast to GDestroyNotify was unnecessary to begin with.
-