1. 15 Mar, 2019 1 commit
  2. 14 Mar, 2019 1 commit
  3. 13 Mar, 2019 2 commits
  4. 12 Mar, 2019 4 commits
    • Vasily Galkin's avatar
      gdbus, tests, win32: test session dbus autolaunch · b245344c
      Vasily Galkin authored
      The test performs implicit autolaunching of a bus
      and checks if it is connectible.
      In build the test is moved from "only non-windows with have_dbus_daemon"
      to "anywhere".
      This is intentional: actually it doesn't execute any external
      binaries on unix (so doesn't require dbus_daemon)
      and now has win32 implementation.
      The test has some problems that are not problems of test itself,
      but are reasoned by current win32 implementation:
       - since the implementation uses global win32 kernel objects
      with fixed names not depending on g_get_user_runtime_dir or other context
      if preexisting bus running by some other libgio-using application
      the test would silently pass.
       - since the implementation uses problematic time-based synchronization,
      that has a race condition between opening and reading mmaped address,
      the test may randomly fail (I'd not seen this in practice).
       - since the implementation autolaunched process works for 3 seconds
      after last client disconnects, the executed subprocess runs for 3 seconds
      after test exit, maybe locking the libgio-2.0-0.dll file for that time.
    • Vasily Galkin's avatar
      gdbus, tests: rename gdbus-unix-addresses test to gdbus-address-get-session · b1f7c22a
      Vasily Galkin authored
      In preparation of adding non-unix testcase to the test.
    • Vasily Galkin's avatar
      gdbus, win32: autolaunch bus with gdbus.exe instead of rundll32 · 8c7670f0
      Vasily Galkin authored
      This is a bit of breaking change:
      After this commit the apps relying of win32 dbus autolaunching,
      need to install gdbus.exe alongside with libgio-2.0-0.dll.
      A new command for gdbus tool is used for running server:
      gdbus.exe _win32_run_session_bus
      To implement it gdbus.exe uses the same exported function
      g_win32_run_session_bus that earlier was used by rundll.
      So (private) ABI was not changed.
      It runs the bus syncronously, exiting after inactivity timeout -
      all exactly like it was runed earlier with the help of rundll32.
      While private exported function may have _some_
      version compatibility issues between gdbus.exe and libgio-2.0-0.dll
      compiling dbus server registration logic directly into gdbus.exe
      can lead to _more hidden and more complex_ compatibility issues
      since the names and behaviour of syncronization objects
      used to publish server address would be required compatible between
      gdbus.exe and libgio-2.0-0.dll.
      So using "private" exported function to call
      looks like more safe behaviour.
      gdbus.exe binary was selected for this task since
      it has corresponding name and at least for msys2 is shippied
      in same package with libgio-2.0-0.dll
      turn_off_the_starting_cursor function is also kept as is,
      however it is not obvious if it is still needed
      (by now I failed reproducing original issue).
      Explicit g_warnings added to help with possible
      problematic cases for absent or incompatible gdbus.exe
      Mainloop is created after successful daemon creation
      Before this change the function leaked mainloop on daemon creation fail
    • Antonio Larrosa's avatar
      Handle an UNKNOWN NetworkManager connectivity as NONE · 2932a58c
      Antonio Larrosa authored
      nm_conn_to_g_conn already handles UNKNOWN like NONE (returning
      G_NETWORK_CONNECTIVITY_LOCAL in both cases). So in sync_properties
      we should also set new_connectivity to G_NETWORK_CONNECTIVITY_LOCAL
      This has the added benefit that when NetworkManager returns the network
      connectivity is UNKNOWN, we set network_available to FALSE as it should
      be. Previously, there were cases in a laptop with no network access,
      that g_network_monitor_get_network_available returned true, which was
      wrong and is also fixed with this commit.
  5. 08 Mar, 2019 4 commits
  6. 07 Mar, 2019 5 commits
  7. 06 Mar, 2019 2 commits
  8. 05 Mar, 2019 2 commits
  9. 04 Mar, 2019 4 commits
  10. 27 Feb, 2019 3 commits
  11. 25 Feb, 2019 3 commits
  12. 22 Feb, 2019 3 commits
  13. 21 Feb, 2019 3 commits
    • Philip Withnall's avatar
      tests: Unmark socket-service test as flaky · 07414e17
      Philip Withnall authored
      This essentially reverts commit
      The preceding two commits have fixed the test so it’s no longer flaky.
      The following command gives 5000 passes in a row for me:
      meson test -C /opt/gnome/build/glib/ socket-service --repeat 5000
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Fixes: #1679
    • Philip Withnall's avatar
      tests: Fix unlikely race in socket-service test · f25c3f27
      Philip Withnall authored
      It’s occasionally possible for the cancellation of the service to happen
      before connection_cb() gets scheduled in the other thread. The
      locking/unlocking order of mutex_712570 requires:
       • test_threaded_712570(): lock mutex
       • test_threaded_712570(): start wait loop
       • connection_cb(): lock mutex
       • test_threaded_socket_service_finalize(): unlock mutex
       • test_threaded_712570(): end wait loop
       • test_threaded_712570(): unlock mutex
      Fix that by quitting the main loop once connection_cb() has been called
      (i.e. once the server thread has received the incoming connection
      request), rather than just after the client thread (main thread) has
      sent a connection request.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Helps: #1679
    • Philip Withnall's avatar
      tests: Fix flaky socket-service test caused by GTask scheduling · 2aea9c84
      Philip Withnall authored
      On about 1 in 3 test runs, the socket-service would fail with the
      ref_count assertion in connection_cb() failing (the ref_count would be 3
      rather than the expected 2).
      This was happening because the GTask from
      g_socket_listener_accept_socket_async() now always takes at least one
      main context iteration to return a result (whereas before
      6f3d57d2 it might have taken zero), but
      the ref_count can drop below 3 before the process of returning a result
      starts. During the process of returning a result, the ref_count
      temporarily increases again, which is what was breaking the test.
      Fix this by waiting for one more main context iteration. This is a bit
      of a hack, but the real fix would be to expose the outstanding_accept
      boolean from GSocketService as public API (which the test can
      interrogate), and that seems too much like exposing internal state.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Helps: #1679
  14. 20 Feb, 2019 3 commits
    • Nirbheek Chauhan's avatar
      meson: Add gobjectenumtypes.h to gioenumtypes_dep · 2d6c4b28
      Nirbheek Chauhan authored
      Almost everything that needs gioenumtypes.h also needs
      gobjectenumtypes.h. Fixes:
      ccache cc @gio/win32/gio@win32@@giowin32@sta/gwin32filemonitor.c.obj.rsp
      In file included from ../gio/win32/gwin32filemonitor.h:25:0,
                       from ../gio/win32/gwin32filemonitor.c:26:
      ../glib/glib-object.h:37:10: fatal error: gobject/gobjectenumtypes.h: No such file or directory
       #include <gobject/gobjectenumtypes.h>
    • Nirbheek Chauhan's avatar
      gio: Also support modules built with MSVC · 8e3fc7df
      Nirbheek Chauhan authored
      GIO modules built with MSVC do not begin with 'lib', but they can
      begin with 'gio'. Without this, you can only load GIO modules built
      with MSVC that are `name.dll`, not `gioname.dll`.
    • Felix Potthast's avatar
      glib-compile-resources: Fixes #1675 · 45655b82
      Felix Potthast authored