datetime: Clean up macros and unused variables

The most complex macros should be converted to inlined functions,
instead, to guarantee some type safety.

datetime: Remove the translation marker for a warning message

docs: Add GDateTime to the GLib API reference

docs: Mention TZDIR

The timezone code in GDateTime honours the TZDIR environment variable,
so it should be mentioned in the list of variables GLib checks at
runtime.

datetime: Add GDateTime to the GType system

As with other GLib data types, use a GBoxed.

Add GDateTime to GLib

GDateTime is an opaque data type containing a date and time
representation. It's immutable once created and reference
counted.

https://bugzilla.gnome.org/show_bug.cgi?id=50076

Based on the code by: Christian Hergert <chris@dronelabs.com>

Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>

Add C_() to glibintl.h

Add const to _pcre_ucp_othercase() definition in pcre_internal.h

Updated Spanish translation

Include gproxyaddress.h explicitly

Improve testutils test coverage

Improve printf test coverage

Improve GDate test coverate

Improve GDBus introspection test coverage

GDBusMethodInvocation: nuke constructor

... that is, make it private. This makes sense because users are never
expected to create such objects themselves - only the GDBus core will
need this.

Signed-off-by: David Zeuthen <davidz@redhat.com>

Updated galician translations

Updated Spanish translation

Bug 624546 – Modification of GDBusMessage in filter function

Allow modifying a GDBusMessage in a filter function and also add tests
for this. This breaks API but leaves ABI (almost) intact - at least
dconf's GSettings backend (the only big user I know of) will keep
working.

https://bugzilla.gnome.org/show_bug.cgi?id=624546

Signed-off-by: David Zeuthen <davidz@redhat.com>

Updated Danish translation

Add proxy extension point to overview docs

The 'Extending GIO' section is supposed to list all extension
points, so add the proxy extension point here.

Fix build on !unix

There was one code block still referring to fd_list outside of
the ifdef G_OS_UNIX. Pointed out by Sam Thursfield in bug 627392.

Better fix for the build problem

Use gnetworkingprivate.h instead, patch by Emilio Pozuelo Monfort,
bug 627407.

Make gdbus-peer build on !linux

Based on a patch by Koop Mast, bug 627088.

Fix a duplicate word

Pointed out in bug 627604.

Add some more annotations

Improve test coverage for actions and action groups

Document behaviour wrt. to floating variants

Document behaviour wrt to floating variants

Add some annotations

Simplify/fix state logic in GAction, test it.

Add some forgotten symbols

Ignore some more private headers

Fix documentation issues

Gtk-doc is unhappy if the parameter names don't match between header
and source.

Fix GActionGroup docs

Updated Serbian translation

Updated Traditional Chinese translation(Hong Kong and Taiwan)

Updated Hebrew translation.

Updated galician translations

Fix misc compiler warnings in (mostly) test programs

gio.symbols: add missing g_simple_action_group stuff

gproxyaddressenumerator.h: add missing G_END_DECLS

gio/proxy: Fixed compilation warnings

* Wrong return type (NULL instead of FALSE)
* Unused static function declaration

Add support for g_socket_client_add_application_proxy()

This allow application to take control over certain proxy protocol
handling. When a proxy protocol must be used and is found in the
application proxies, GSocketClient will simply TCP connect to the proxy
server and return the connection.

Reviewed-by: Dan Winship <danw@gnome.org>

Implemented SOCKSv4 and SOCKSv4a

Implemented proxy sample code that connect to proxy

Implemented g_socket_client_connect_to_uri() method

Using this rather than g_socket_client_connect() or
g_socket_client_connect_to_host() allows #GSocketClient to
determine when to use application-specific proxy protocols.

Reviewed-by: Dan Winship <danw@gnome.org>

Hooked proxy enumeration into GSocketClient

This functionnallity can be disabled using property enable-proxy. It
enumerates addresses using GSocketConnectable::proxy_enumerate() instead of
enumerate(). When the returned address is of type GProxyAddress (a type
based on GInetSocketAddress), it gets the proxy protocol handler using
g_proxy_get_default_for_protocol() and call connect() on it.

Reviewed-by: Dan Winship <danw@gnome.org>

Implement GProxyConnection a GIOStream+GTcpConn wrapper

This class inherit from GTcpConnection by refing the socket of
an existing GTcpConnection and wraps a custom GIOStream into itself. This
is to allow implementing proxies that alters data stream, like when using
GSSAPI privacy inside SOCKS5.

Implemented SOCKSv5 proxy support

GSocket: store the remote_address when connecting

This way, if g_socket_connect() is called with a GProxyAddress,
g_socket_get_remote_address() will later return that same address.

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk>

Extend IO_ERROR enum for Proxy support

Implemented proxy sample for all Connectables

Implemented proxy_enumerate() for all Connectables

This patch implements method proxy_enumerate from GSocketConnectable for
all connectables (GNetworkAddress, GNetworkService, GInetSocketAddress
and GUnixSocketAddress).

Reviewed-by: Dan Winship <danw@gnome.org>

Added proxy_enumerate method to GSocketConnectable

Reviewed-by: Dan Winship <danw@gnome.org>

Added GProxyAddressEnumerator to proxy sample code

Adding GProxyAddressEnumerator class

An implementation of GSocketAddressEnumerator that handles proxy
enumeration. This class is mainly usefull for Connectables implementation
such as NetworkService, NetworkAddress and SocketAddress to handle proxies.

Reviewed-by: Dan Winship <danw@gnome.org>

Added GProxy interface for proxy extension point

Implement an extension point for proxy protocol implementation. This
is mainly useful for socket-based proxy where it is possible to use the
proxied socket the same way it would for other stream based socket.

Reviewed-by: Dan Winship <danw@gnome.org>

Added method g_network_address_parse_uri()

This method allow creating a network address from a URI. If no port is
found in the URI, the default_port parameter will be used. Note that new
property scheme is there for future TLS implementation.

Reviewed-by: Dan Winship <danw@gnome.org>

Implement GProxyAddress

A GSocketInetAddress representing the proxy server address with additional
properties proxy type, destination address and port, username and password.

Reviewed-by: Dan Winship <danw@gnome.org>

Implemented proxy sample code

Reviewed-by: Dan Winship <danw@gnome.org>

Implemented proxy-resolver extension point

This extension point allow extending GLib with library like LibProxy that
interprets system proxy settings and finds the appropriate configuration
based on the type of connection being made.

Reviewed-by: Dan Winship <danw@gnome.org>

Updated Spanish translation

Updated Hebrew translation.

Bug 627188 – gdbus-non-socket test occasionally fails

Fix logical bug in test case to avoid race condition between the
client and the server.

Signed-off-by: David Zeuthen <davidz@redhat.com>

Make gunixcredentialsmessage.h standalone includable

action: Minor fixes

• Argument validation.

• Since: annotations.

• Remove (allow-none) annotations from return values.

• Coding style fixes.

action-group: Check aginst the correct GType macro

G_TYPE_ACTION_GROUP is not a G_TYPE_ACTION.

GDBusProxy: Call into well-known name if no name owner currently exists

This is really what (API) users expect from GDBusProxy - in
particular, mclasen and I ran into this problem while debugging a
upower issue, see

 https://bugzilla.redhat.com/show_bug.cgi?id=624125

In a nutshell, the problem is that polkitd crashes while upower holds
a PolkitAuthority object (which in turns contains a GDBusProxy for the
well-known name org.freedesktop.PolicyKit1). This means that
subsequent calls on the PolkitAuthority (which is translated into
calls into the GDBusProxy) fails since :g-name-owner is NULL.

With this fix, we'll be requesting the bus daemon to launch polkitd
since we will start calling into org.freedesktop.PolicyKit1 as soon as
we notice that there is no owner for this name.

Unfortunately our test suite doesn't cover service activation so there
is no way to reliably test this. I will file a bug about this.

Signed-off-by: David Zeuthen <davidz@redhat.com>

GDBusProxy: Use %, not #, for referencing enum constants in gtk-doc comments

Signed-off-by: David Zeuthen <davidz@redhat.com>

G_OPTION_FLAG_NO_ARG is only for callback options

Bug #627252.

add GSimpleActionGroup

and a simple test

add some missed bits in the docs

add gaction.h to gio.h

add testcase for GAction

fix some small bugs it found

add GAction base class

gio.symbols: Fix missed symbol name tweak

pad the GActionGroup vtable

Add gactiongroup.h to gio.h

add GActionGroup base class

update gio/tests/.gitignore

Plug a mem leak in GDBusWorker

Free the read buffer.

==26538== 4,096 bytes in 1 blocks are definitely lost in loss record 781 of 781
==26538==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==26538==    by 0x4005C66: realloc (vg_replace_malloc.c:476)
==26538==    by 0x405244D: g_realloc (gmem.c:181)
==26538==    by 0x420E066: _g_dbus_worker_do_read_unlocked (gdbusprivate.c:780)
==26538==    by 0x420E1D1: _g_dbus_worker_do_read (gdbusprivate.c:812)
==26538==    by 0x420F14A: _g_dbus_worker_thread_begin_func (gdbusprivate.c:1318)
==26538==    by 0x420D2ED: invoke_caller (gdbusprivate.c:266)
==26538==    by 0x404DA7C: g_idle_dispatch (gmain.c:4224)
==26538==    by 0x4049FCD: g_main_dispatch (gmain.c:2119)
==26538==    by 0x404B2C1: g_main_context_dispatch (gmain.c:2672)
==26538==    by 0x404B716: g_main_context_iterate (gmain.c:2750)
==26538==    by 0x404BE7F: g_main_loop_run (gmain.c:2958)
==26538==    by 0x420D2B5: shared_thread_func (gdbusprivate.c:248)
==26538==    by 0x4077958: g_thread_create_proxy (gthread.c:1897)
==26538==    by 0x57D918: start_thread (pthread_create.c:301)
==26538==    by 0x4C6CBD: clone (clone.S:133)

Bug #627187.

Plug a mem leak in gdbus-connection test

==26538== 145 (24 direct, 121 indirect) bytes in 1 blocks are definitely lost in loss record 765 of 790
==26538==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==26538==    by 0x405233C: g_malloc (gmem.c:134)
==26538==    by 0x406A57E: g_slice_alloc (gslice.c:836)
==26538==    by 0x406A60C: g_slice_copy (gslice.c:858)
==26538==    by 0x4035C5A: g_error_copy (gerror.c:160)
==26538==    by 0x41B6387: g_simple_async_result_set_from_error (gsimpleasyncresult.c:638)
==26538==    by 0x41FCDEB: g_dbus_connection_call_done (gdbusconnection.c:4808)
==26538==    by 0x41B682E: g_simple_async_result_complete (gsimpleasyncresult.c:762)
==26538==    by 0x41B686A: complete_in_idle_cb (gsimpleasyncresult.c:772)
==26538==    by 0x404DA7C: g_idle_dispatch (gmain.c:4224)
==26538==    by 0x4049FCD: g_main_dispatch (gmain.c:2119)
==26538==    by 0x404B2C1: g_main_context_dispatch (gmain.c:2672)
==26538==    by 0x404B716: g_main_context_iterate (gmain.c:2750)
==26538==    by 0x404BE7F: g_main_loop_run (gmain.c:2958)
==26538==    by 0x804B5CC: test_connection_send (gdbus-connection.c:407)
==26538==    by 0x4073D04: test_case_run (gtestutils.c:1174)

Bug #627187.

Plug a mem leak in gdbus-connection test

==25403== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 603 of 787
==25403==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==25403==    by 0x405233C: g_malloc (gmem.c:134)
==25403==    by 0x406A57E: g_slice_alloc (gslice.c:836)
==25403==    by 0x406A5C3: g_slice_alloc0 (gslice.c:848)
==25403==    by 0x4035B4E: g_error_new_literal (gerror.c:117)
==25403==    by 0x4035ED9: g_set_error_literal (gerror.c:314)
==25403==    by 0x41F6434: g_dbus_connection_close_sync (gdbusconnection.c:1284)
==25403==    by 0x804A861: test_connection_life_cycle (gdbus-connection.c:158)
==25403==    by 0x4073D04: test_case_run (gtestutils.c:1174)
==25403==    by 0x4073FC2: g_test_run_suite_internal (gtestutils.c:1223)
==25403==    by 0x4074077: g_test_run_suite_internal (gtestutils.c:1233)
==25403==    by 0x4074077: g_test_run_suite_internal (gtestutils.c:1233)
==25403==    by 0x40741FB: g_test_run_suite (gtestutils.c:1274)
==25403==    by 0x40733E5: g_test_run (gtestutils.c:877)
==25403==    by 0x804DC92: main (gdbus-connection.c:1024)

Bug #627187.

Plug a mem leak in the gdbus-connection test

Bug #627182.

Use g_memory_output_stream_steal_data here

... instead of one extra g_memdup().

Bug #627181.

Use G_DEFINE_[BOXED|POINTER]_TYPE instead of handwritten code

Now that we have convenience macros to implement boxed and pointer
types, use them.

Add G_DEFINE_{BOXED,POINTER}_TYPE[_WITH_CODE]

Add convenience type definition macros for boxed and pointer types
similar to G_DEFINE_TYPE for object types. Bug #449565.

Add GZIP header processing to GZlibCompressor/GZlibDecompressor

Add GZlibCompressor:file-info property. If it contains a non-NULL
GFileInfo, and the compressor is in GZIP mode, the filename and
modification time from the file info are written to the GZIP header
in the output data.

Add GZlibDeompressor:file-info property. If the decompressor is in GZIP
mode, and the GZIP data contains a GZIP header, the filename and
modification time are read from it, stored in a GFileInfo, and the
file-info property is notified.

Bug #617691.

Add g_memory_output_stream_steal_data

Bug #622184.

Bump version

Fix a typo

Add NEWS item for bug 627071

Signed-off-by: David Zeuthen <davidz@redhat.com>

Bug 627071 – g_output_stream_write() clarification

This patch guarantees that g_output_stream_write() can never fail with
G_IO_ERROR_WOULD_BLOCK. Without such a guarantee, we would need some
kind of GIOPollable interface or some way to get an event when the
stream is writable again. Which is mostly useless considering that
this method is asynchronous anyway.

Note: this patch just codifies existing behavior - GUnixOutputStream,
GSocketOutputStream and other implementations already work this way.

See also bug 626748 comment 5 for how the GDBus code relies on this
guarantee.

https://bugzilla.gnome.org/show_bug.cgi?id=627071

Signed-off-by: David Zeuthen <davidz@redhat.com>

More NEWS

Fix a doc format issue

Update NEWS for 2.25.14

Bug 626748 – Use async methods for writing and handle EAGAIN

If sending a lot of data and/or the other peer is not reading it, then
socket buffers can overflow. This is communicated from the kernel by
returning EAGAIN. In GIO, it is modelled by g_output_stream_write()
and g_socket_send_message() returning G_IO_ERROR_WOULD_BLOCK.

It is also problematic that that we're using synchronous IO in the
shared GDBus IO thread. It means that one GDBusConnection can lock up
others.

It turns out that by porting from g_output_stream_write() to
g_output_stream_write_async() we fix the EAGAIN issue. For GSocket, we
still need to handle things manually (by creating a GSource) as
g_socket_send_message() is used.

We check the new behavior in Michael's producer/consumer test case (at
/gdbus/overflow in gdbus-peer.c) added in the last commit.

Also add a test case that sends and receives a 20 MiB message.

Also add a new `transport' G_DBUS_DEBUG option so it is easy to
inspect partial writes:

 $ G_DBUS_DEBUG=transport ./gdbus-connection -p /gdbus/connection/large_message
 [...]
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 128000 bytes of message with serial 4 and
        size 20971669 from offset 0 on a GSocketOutputStream
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 128000 bytes of message with serial 4 and
        size 20971669 from offset 128000 on a GSocketOutputStream
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 128000 bytes of message with serial 4 and
        size 20971669 from offset 256000 on a GSocketOutputStream
 [...]
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 43669 bytes of message with serial 4 and
        size 20971669 from offset 20928000 on a GSocketOutputStream
 [...]
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 16 bytes of message with serial 3 and
        size 20971620 to offset 0 from a GSocketInputStream
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 15984 bytes of message with serial 3 and
        size 20971620 to offset 16 from a GSocketInputStream
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 16000 bytes of message with serial 3 and
        size 20971620 to offset 16000 from a GSocketInputStream
 [...]
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 144000 bytes of message with serial 3 and
        size 20971620 to offset 20720000 from a GSocketInputStream
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 107620 bytes of message with serial 3 and
        size 20971620 to offset 20864000 from a GSocketInputStream
 OK

https://bugzilla.gnome.org/show_bug.cgi?id=626748

Signed-off-by: David Zeuthen <davidz@redhat.com>

GSocket: Properly initialize msg.msg_control

This patch fixes this problem

   Syscall param socketcall.sendmsg(msg.msg_control) points to uninitialised byte(s)
      at 0x3D5B00EA60: __sendmsg_nocancel (syscall-template.S:82)
      by 0x53F9790: g_socket_send_message (gsocket.c:2918)
      by 0x540FDD0: g_unix_connection_send_credentials (gunixconnection.c:351)
      by 0x542B93F: _g_dbus_auth_run_client (gdbusauth.c:618)
      by 0x5438001: initable_init (gdbusconnection.c:2191)
      by 0x53E09CC: g_initable_init (ginitable.c:105)
      by 0x543F6E9: g_bus_get_sync (gdbusconnection.c:6091)
      by 0x402C7E: test_connection_life_cycle (gdbus-connection.c:126)
      by 0x4C7CABB: test_case_run (gtestutils.c:1174)
      by 0x4C7CD84: g_test_run_suite_internal (gtestutils.c:1223)
      by 0x4C7CE49: g_test_run_suite_internal (gtestutils.c:1233)
      by 0x4C7CE49: g_test_run_suite_internal (gtestutils.c:1233)
    Address 0x7fefff9fc is on thread 1's stack

Signed-off-by: David Zeuthen <davidz@redhat.com>

Declare stream base classes as abstract

Always do async vs sync correctly in GSocketConnection streams

Previously if a GSocketConnection had a blocking GSocket, it would
sometimes block during asynchonous I/O, and if it had a non-blocking
socket, it would sometimes return G_IO_ERROR_WOULD_BLOCK from
synchronous I/O. This fixes the connection to not depend on the socket
state.

https://bugzilla.gnome.org/show_bug.cgi?id=616458