1. 20 Jan, 2019 1 commit
  2. 17 Jan, 2019 1 commit
  3. 09 Jan, 2019 1 commit
  4. 16 Dec, 2018 1 commit
  5. 12 Dec, 2018 2 commits
  6. 05 Dec, 2018 3 commits
  7. 28 Nov, 2018 1 commit
  8. 27 Nov, 2018 7 commits
    • Debarshi Ray's avatar
    • Debarshi Ray's avatar
      httpclient: Style fixes · 5cab7b7f
      Debarshi Ray authored
      5cab7b7f
    • Debarshi Ray's avatar
    • Debarshi Ray's avatar
      httpclient: Make the GCancellable handling thread-safe · e9114fe4
      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.
      e9114fe4
    • Debarshi Ray's avatar
      httpclient: Ensure that the GTask is always cleaned up · 0476f2ed
      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
      0476f2ed
    • Debarshi Ray's avatar
      ewsclient: Simplify the clean up · 730e84ac
      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
      730e84ac
    • Debarshi Ray's avatar
      httpclient: Simplify the clean up · 43ac806d
      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
      43ac806d
  9. 26 Nov, 2018 2 commits
  10. 23 Nov, 2018 4 commits
  11. 28 Oct, 2018 1 commit
  12. 16 Oct, 2018 1 commit
  13. 03 Oct, 2018 1 commit
  14. 01 Oct, 2018 1 commit
  15. 05 Sep, 2018 1 commit
  16. 01 Sep, 2018 3 commits
  17. 20 Aug, 2018 1 commit
  18. 16 Aug, 2018 4 commits
    • Debarshi Ray's avatar
      dd6bd39c
    • Debarshi Ray's avatar
      Prepare 3.29.91 · 4277e074
      Debarshi Ray authored
      4277e074
    • Debarshi Ray's avatar
      build: Silence warning about _FORTIFY_SOURCE requiring optimization · 9214b289
      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
      9214b289
    • Debarshi Ray's avatar
      build: Turn off -Wcast-function-type · 2b981374
      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.
      2b981374
  19. 20 Jul, 2018 4 commits