gio: add G_IO_ERROR_NOT_CONNECTED

It adds a new error G_IO_ERROR_NOT_CONNECTED
and makes the win32 error ERROR_PIPE_LISTENING
to be translated to it.

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

docs: Add index for 2.44 api

Updated Vietnamese translation

Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>

gsocket: add G_IO_ERROR_CONNECTION_CLOSED

Add G_IO_ERROR_CONNECTION_CLOSED as an alias for
G_IO_ERROR_BROKEN_PIPE, and also return it on ECONNRESET.

It doesn't really make sense to try to distinguish EPIPE and
ECONNRESET at the GLib level, since the exact choice of which error
gets returned in what conditions depends on the OS. Given that, we
ought to map the two errors to the same value, and since we're already
mapping EPIPE to G_IO_ERROR_BROKEN_PIPE, we need to map ECONNRESET to
that too. But the existing name doesn't really make sense for sockets,
so we add a new name.

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

gnetworkaddress: Add g_network_address_new_loopback() constructor

This is a convenience method for creating a GNetworkAddress which is
guaranteed to return IPv4 and IPv6 loopback addresses. The program
cannot guarantee that 'localhost' will resolve to both types of
address, so programs which wish to connect to a local service over
either IPv4 or IPv6 must currently manually create an IPv4 and another
IPv6 socket, and detect which of the two are working. This new API
allows the existing GSocketConnectable machinery to be used to
automate that.

Based on a patch from Philip Withnall.

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

GVariant tests: test with larger strings

Allocate some larger strings in the testcase to make sure we handle them
correctly as well.

gmain: fix poll record comparison

We intend to keep the list of poll records sorted by (integer) file
descriptor, but due to a typo we are actually keeping it sorted by
pointer address of the GPollFD.

Fix that.

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

gsignal: add a clarification to the docs

As evidenced by a mistake that I made recently, this documentation could
use a little bit of clarification.

GSettings: fix check for delaying backend subscription

g_settings_has_signal_handlers() checks whether any of the signals has
pending handlers. However, g_signal_has_handler_pending() matches on
exact detail, even when passing 0. Subscribing to one of GSettings'
signals with a detail will fail this check and never connect to the
backend.

Fix this by calling has_handler_pending() with the key as detail as
well.

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

Use the new g_strv_contains

No need to keep our own copy of this in the testsuite.

gstrfuncs: Add g_strv_contains()

Includes unit tests.

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

packaging: Bump to 2.43.1

Change-Id: Id068a8288f85baef2ffada606d10bcb2dbf78cf4
Bug-Tizen: TC-2124
Signed-off-by: Philippe Coval <philippe.coval@open.eurogiciel.org>

packaging: Bump to 2.40.1

Change-Id: I23e399e680e58b26358c00e15cd4325c5eb08338
Signed-off-by: Philippe Coval <philippe.coval@open.eurogiciel.org>

packaging: Bump to 2.40.0

Change-Id: I6d64c12841cc6d0c536e27f1f3d69ec3a675d7d6
Bug-Tizen: PTREL-773
Bug-Tizen: TIVI-2898/part
Signed-off-by: Philippe Coval <philippe.coval@open.eurogiciel.org>

add .gbs.conf and update to 2.36.4

Change-Id: I0540f90b0b0ba28680cd5ae1d5186d07be078e61
Signed-off-by: Anas Nashif <anas.nashif@intel.com>

resetting manifest requested domain to floor

changes: Bug-Tizen: TZPC-3317 (... remove the fav apps icon ...)

Conflicts:
packaging/glib2.changes

Remove empty docs package

remove docs package

Signed-off-by: Anas Nashif <anas.nashif@intel.com>

Update to 2.36.1

Update to 2.36.0

Update to 2.35.9

Remove previous crash fix (TZPC-453)

Update to 2.35.8

Update to 2.35.8

Update to 2.35.7

cleanup spec file

Update to 2.35.4

Update to 2.35.4

split commit

update to 2.35.3

add changelog

package license file

add codegen to %files

BR glibc-devel

adapt %files section

update to 2.35.2

cleanup %files

cleanup %files

run autogen

add packaging

2.43.1

gio/tests: add a socket-listener test

Add a GSocketListener test program. Currently the only test is a
regression test for bug 712570 (based on a standalone bug reproducer
provided by Ross Lagerwall).

gio: Prevent hang when finalizing GThreadedSocketService

If all users of a GThreadedSocketService release their references to the
service while a connection thread is running, the thread function will
release the last reference to the service which causes the finalize to
deadlock waiting for all threads to finish (because it's called from the
thread function).

To fix this, don't wait for all threads to finish in the service's
finalize method.  Since the threads hold a reference to the service,
finalize should only be called when all threads are finished running (or
have unrefed the service and are about to finish).

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

gparam: Make the documentation clearer for CONSTRUCT_ONLY properties

It's not that the properly will only be set on construction, it's that
it *can* only be set upon construction.

gio: Implement g_win32_app_info_launch_uris for windows.

gio: Implement g_app_info_get_default_for_uri_scheme for windows.

GTlsClientConnection: loosen the semantics of "use-ssl3"

If SSL 3.0 has been disabled (at the host, application, or library
level), then the "use-ssl3" property becomes a "fail-immediately"
property.

Despite the name, the point of the property wasn't really specifically
to use SSL 3.0; it was to allow fallback when talking to broken
servers that do SSL/TLS negotiation incorrectly and break when they
see unexpectedly-high version numbers. So if we can't fall back to SSL
3.0, then the "use-ssl3" property should fall back to TLS 1.0 instead
(since there are hosts that will reject a TLS 1.2 handshake, but
accept a TLS 1.0 one).

glib-networking is being updated to implement that behavior, so update
the documentation here.

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

GSettings Registry Backend: Init cache_lock Earlier

In commit 8ff5668, we are subscribing the GSettings backend later, but this
meant that we need to initialize cache_lock earlier, as we might try to
use that lock before a change notification is issued to subscribe the
backend, which would then cause an access violation if we are trying to
read GSettings values, as that lock is used to access the Windows Registry.

Initialize cache_lock once we initialize the GSettings Registry backend,
and delete it upon finalize, so that g_settings_read_from_backend() can
proceed normally, even if the GSettings backend is not yet subscribed.

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

gsettingsschema: Print the string that failed to parse

When parsing a translated value fails, print the actual string that
failed to parse instead of the 'domain\004string' untranslated string.

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

GSettings: delay backend subscription

GSettings objects begin watching for changes as soon as they are created
in order that they can emit the "changed" signal.

In the case of dconf, if we want to be able to emit the changed signal,
we need to go on the bus and add some match rules.  This requires
creating the dconf helper thread and also requires initialising GDBus
(which creates another thread).

Some users of GSettings are never interested in the "changed" signal.
One of these users is the glib-networking code that gets run every time
a new network connection is created.

Some users are reporting that they are annoyed that simply establishing
a network connection would spawn two extra threads and create a D-Bus
connection.

In order to avoid doing unnecessary work for these simple uses, delay
the subscription until we know that we will actually need to do it.

We do this in a simple way, using a simple argument: in order for the
user to care that a value changed then they must have:

 1) watched for a change signal; and then
 2) actually read a value

If the user didn't actually read a value then they cannot possibly be
interested in if the value changed or not (since they never knew the old
value to begin with and therefore would be unable to observe that it
ever changed, since they have nothing to compare the new value with).

This really is a behaviour change, however, and it does impact at least
one user: the 'monitor' functionality of the GSettings commandline tool,
which is interested in reporting changes without ever having known the
original values.  We add a workaround to the commandline tool in order
to ensure that it continues to function properly.

It's also possible to argue that it is completely valid to have read a
value and _then_ established a change signal connection under the
(correct) assumption that it would not have been possible to miss a
change signal by virtue of not having returned to the mainloop.
Although this argument is true, this pattern is extremely non-idiomatic,
and the problem is easily avoided by doing things in the usual order.

We never really talked about change notification in the overview
documentation for GSettings, so it seems like now is a good time to add
some discussion, including the new rules for when one can expect change
signals to be emitted.

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

glib: Improve documentation for g_strfreev()

Fixes #740309.

Updated Norwegian bokmål translation.

gapplication: enable --help when app has options

This should already work according to the documentation, but doesn't
because main_options is consumed before the check in
g_application_parse_command_line().

Fix by moving the check for main_options up.

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

docs: Add missing opening parenthesis

https://mail.gnome.org/archives/gnome-web-list/2014-November/msg00003.html

docs: Update GParamFlags docs.

Remove reference to G_PARAM_READWRITE from GParamFlags' description,
since commit 6c395244a5db added G_PARAM_READWRITE to GParamFlags.

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

Simplify code that uses g_queue_insert_before() and insert_after()

g_queue_insert_before() and g_queue_insert_after() now accept a NULL
sibling.

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

GQueue: accept a NULL sibling for insert_before() and insert_after()

It simplifies a little bit some code that inserts data relative to a
GList location, that might be NULL for the tail of the queue. A NULL
sibling is probably less useful for insert_after(), so it's more for
consistency with insert_before().

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

gnetworking.h.win32: Move "#undef interface"

This is a follow-up commit due to the fix in gnetworking.h.in in commit
7103484 (gnetworking.h.in: move "#undef interface").

gnetworking.h.in: move "#undef interface"

The win32 headers do:

  #define interface struct

which is just evil and breaks other code that assumes it can use
"interface" as a variable name. gnetworking.h was supposed to be doing
"#undef interface" after including the win headers, but it did it too
soon, resulting in it getting redefined by a later include. Fix this.

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

GTlsCertificate: fix loading of bad certificate chains

g_tls_certificate_new_from_file() was only loading the complete chain
if it was fully valid, but we only meant to be validating that it
formed an actual chain (since the caller may be planning to ignore
other errors).

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

doc: Clarify documentation regarding g_file_replace and etags

Clarify that with g_file_replace, a non-NULL etag is only checked if the
file already exists.

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

gio: Prevent hang writing to a large GMemoryBuffer

Fix a hang due to overflow by using unsigned numbers and explicitly
checking if the number overflows to zero.  This also fixes the previous
logic which assigned an int which may be negative to an unsigned number
resulting in sign extension and strange results.

Use gsize rather than int to allow for large buffers on 64 bit machines.

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

gio: Prevent hang writing to a large GMemoryOutputStream

Fix a hang due to overflow by using unsigned numbers and explicitly
checking if the number overflows to zero.  This also fixes the previous
logic which assigned an int which may be negative to an unsigned number
resulting in sign extension and strange results.

Use gsize rather than int to allow for large streams on 64 bit machines.

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

gmain: don't pass the same fd to g_poll() multiple times

If a given fd is being polled by multiple sources, we used to pass it
multiple times to g_poll(), which is technically illegal (and not
supported by the select()-based fallback implementation of poll() in
gpoll.c), and also made it more likely that we'd exceed the maximum
number of pollfds.

Fix it to merge together "duplicate" GPollFDs. The easiest way to do
this involves re-sorting context->poll_records into fd order rather
than priority order. This means we now have to walk the entire pollrec
list for every g_main_context_query() and g_main_context_poll(),
rather than only walking the list up to the current max_priority.
However, this will only have a noticeable effect if you have tons of
GPollFDs, and we're already too slow in that case anyway because of
other O(n) operations that happen too often. So this shouldn't change
much (and the new poll API will eventually let us be cleverer).

Remove some win32-specific code which did the same thing (but was
O(n^2)).

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

GDBusInterfaceVTable: clarify memory handling for the method() virtual function

There are two consistent interpretations that could be taken for memory
handling of the 'invocation' parameter passed to the method_call() virtual
function of GDBusInterfaceVTable

 - A reference is passed (transfer full) to the method_call() virtual function,
   and that reference is then passed (transfer full) to the return_value/error
   functions on GDBusMethodInvocation.
 - An internal reference is retained from the point where method_call() is called
   until the return_value/error function is called.

Since the return_value/error functions were already marked (transfer full),
we use the first interpretation, annotate the invocation parameter of
method call as (transfer full) and describe this in the documentation, along
with the idea that you are always supposed to call one of the return_value/error
functions.

See bug 738122 for the leak this caused in GJS.

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

Updates for 2.43.0

gcancellable: Clarify that GSources hold references to GCancellables

Clarify in the documentation that a GSource created with
g_cancellable_source_new() must be explicitly removed from its
GMainContext before the GCancellable can be finalised.

This could be a common way of leaking GCancellables.

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

Guard g_inet_address_mask_equal against invalid input

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

gio/tests/tls-certificates: fix

da053e34 broke the tls-certificates test by requiring the backend to
implement g_tls_certificate_verify() (which the test TLS backend
didn't). Add a trivial implementation to make the test pass again;
we'll need something more complicated when we add tests that are
supposed to get errors.

gfile: g_file_equal (x, x) is TRUE

So shortcut it.

I wrote this patch less as a performance optimization and more as a
clarification, so that people looking at the code can be assured of this
invariant.

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

Add tests for {read,write}_all_async()

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

docs: explain inconsistency of _{read,write}_all()

These functions are inconsistent with our normal conventions in that
they set an output variable to a specified value, even in the case that
an error is thrown.

Document very clearly that this should be considered exceptional.

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

Add g_output_stream_write_all_async()

Similar to the previous patch, this commit contains a minor violation of
normal API conventions.  See the explanation in the previous commit
message.

Heavily based on a patch from Ignacio Casal Quinteiro.

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

Add g_input_stream_read_all_async()

Add an asynchronous version of _read_all().

This API is not fully consistent with the normal expectations of a
non-asynchronous version.  Consistency between the sync and async version is
probably more important.

The API will still bind correctly, but access to all functionality will
not be available: specifically, in the case of an error, higher level
languages will be unable to determine how many bytes were successfully
read before the error.  Most users will probably not want to use this
information anyway, so this is OK -- and if they do need the
information, then they can just write the loop for themselves.

Heavily based on a patch from Ignacio Casal Quinteiro.

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

Fix another ancient docs typo

GApplication: ignore --help if not handling args

If the user didn't register any arguments for parsing, also ignore
--help.  This fixes a regression in meld.

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

GOption: stop calling getopt()

We called getopt() to try to find out of the platform on which we are
running defaults to strict POSIX-style argument handling (ie: flags
following the first filename are considered as further filenames rather
than flags).

This is the default case on BSDs, for example.  It is also the case on
GNU systems with the POSIXLY_CORRECT environment variable set.

Unfortunately many of our tools rely on being able to accept commandline
arguments in the non-strict ordering and the code for making these calls
is spread widely (for example in Makefile fragments invoking some of our
build tools).

For this reason we need to revert the getopt() check and only enable
strict POSIX mode in the case that the application explicitly opts into
it using the _set_strict_posix() API.

This also fixs a failure to build on Windows due to missing getopt().

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

GHashTable: small docs fix

We use g_hash_table_unref() here, not g_object_unref().

Allow hash table destroy notifiers to remove other entries

With this patch it is fine to call g_hash_table_lookup and
g_hash_table_remove from destroy notification functions. Before
this could lead to an infinitie loop if g_hash_table_remove_all
was used.

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

docs: Add missing get_type() reference to gio.types

GSubprocessLauncher is a GObject, so we need to tell gtk-doc to inspect
it.

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

GOption: add strict posix mode

Add a "posixly correct" mode to GOption to stop parsing arguments as
soon as the first non-option argument is encountered.

We determine the default value on the basis of duplicating the behaviour
of the system getopt() implementation (which we directly check the
behaviour of at runtime).  On GNU systems this allows the user to modify
our behaviour using POSIXLY_CORRECT.

The user can change the value by g_option_context_set_strict_posix(),
which might be useful for some usecases of GOptionContext (as mentioned
in the doc string of this new function).

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

GApplication: Plug a memory leak

We were not freeing resource_path.

gdesktopappinfo: Fix copy/paste typo from e24e89b

Commit e24e89b accidentally ironically introduced a typo when replacing
the code with symbolic contents. Specifically, "Added Associations" was
replaced with "Default Applications" when reading defaults.list, giving
a warning about the file containing a "Default Applications" group.

If this was intended, it should have not been lumped in with a cleanup.

gfile: Clarify docs

Clarify corner cases that were unclear while reviewing a GTK patch.

Bump version to 2.43.0

We have new API.

signal: Keep only one list of emissions

There is no need to keep 2 lists.

This simplifies the code and gets rid of the only user inside glib of
G_HAVE_GROWING_STACK.

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

Fix a return_if_fail confusion

This slipped through my editing of the patch.

Add simple instance count facility

Add GOBJECT_DEBUG=instance-count which enables internal accounting
of the number of instances of each GType, and g_type_get_instance_count()
to retrieve the result.

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

Updated Bulgarian translation

Clarify g_propagate_error docs

I just ran into a bug that was caused by having src being a
persistent GError* that was not cleared after propagating it.

Fix g_cond_timed_wait() timeout with !CLOCK_MONOTONIC

g_get_monotonic_time() and g_get_real_time() now always use different
clocks, so we cannot avoid correcting for their offset.  Fixes failure
to time out on Mac OS X.

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

garray: initialize allocated size in g_byte_array_new_take()

Internal allocation size (array->alloc) was being kept to 0 when a new
GByteArray was created from an already existing heap-allocated buffer.

Among other things, this was making g_byte_array_set_size() fully clear all
the buffer contents (not just the newly allocated memory) when
G_DEBUG=gc-friendly was being used...

  if (G_UNLIKELY (g_mem_gc_friendly))
    memset (array->data + array->alloc, 0, want_alloc - array->alloc);

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

Add advice on g_cancellable_reset

Don't use it at home.

tlscertificate: add support for certificate chains

This patch changes the behavior of the following functions:

   g_tls_certificate_new_from_pem
   g_tls_certificate_new_from_file
   g_tls_certificate_new_from_files

If more than one certificate is found it will try to load the chain.

It is assumed that the chain will be in the right order (top-level
certificate will be the last one in the file). If the chain cannot be
verified, the first certificate in the file will be returned as before.

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

Fix typo

Updated Italian translation

GDataSet: Add more tests

These tests exercise the NULL key fix from the previous commit.

GDataSet: silently accept NULL/0 as keys

This used to be the behaviour before we made these functions
threadsafe; keep it that way.

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

gdesktopappinfo: Use symbolic names in the code

We have #defines for the key file groups, so use them to avoid typos.

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