Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
Reviewed-by: George Kiagiadakis <gkiagia@tolabaki.gr>
|
|
|
|
|
|
telepathy-gabble-0.18
|
|
Fix https://bugs.freedesktop.org/show_bug.cgi?id=76465
|
|
|
|
* data-form: reformat <code> blocks so recent gtk-doc can cope
* jingle-content: reset idle ID in its callback
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66085
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
Also, use token constants when possible.
|
|
Fix a crash on 64 bits archs.
https://bugs.freedesktop.org/show_bug.cgi?id=70038
|
|
Thanks clang...
https://bugs.freedesktop.org/show_bug.cgi?id=70038
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68829
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
|
|
|
|
Needed to fix connection to Facebok (fdo#68829).
|
|
|
|
|
|
|
|
This fails during parallel distcheck.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=67953
|
|
[Commit message added -smcv]
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714534
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=67875
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=67900
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
|
|
Conflicts:
NEWS
|
|
|
|
Before telepathy-glib 0.20.3 and 0.21.1, we had this incorrect sequence
(pseudocode) for each group:
* NewChannels(the group)
* GroupsChanged([the group], added: [...], removed: [])
* NewChannels(the group)
In 0.20.3 and 0.20.1, we removed the second emission of NewChannels.
Unfortunately, that broke this test, which was specifically expecting
GroupsChanged followed by NewChannels.
Rather than reversing the assumption, I'm doing it properly, by
expecting the events in no particular order.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=67828
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
The Python invocation is indented, because it's a command-line argument
for the sh invocation. The case shouldn't be.
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65290
|
|
I need these so that hazetest can just override what it needs, rather
than actually modifying the copy of gabbletest.
https://bugs.freedesktop.org/show_bug.cgi?id=65658
|
|
|
|
|
|
A rule like this:
_gen/x.c _gen/x.h: prerequisites
$(AM_V_GEN)x-generator
doesn't consider x.c and x.h together. Instead, it expands to two rules,
one to generate x.c and one to generate x.h, which happen to run the
same commands.
This means that in the worst case, you can end up running x-generator
twice in parallel, and they'll race with each other and overwrite or
delete each other's output.
Based on commit 36c2a545c from telepathy-glib.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=64285
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
Conflicts:
extensions/Makefile.am
|
|
|
|
When autoreconfiscated with Automake 1.13, the way in which we were
(ab?)using Automake's test driver no longer works. We can't just
switch back to the old serial test driver without a dependency on
at least Automake 1.12, either. However, run-test.sh (which was already
used for installed tests) is quite capable of running uninstalled
tests, with a bit of adjustment:
* if GABBLE_TEST_UNINSTALLED is set, expect GABBLE_ABS_TOP_SRCDIR,
GABBLE_ABS_TOP_BUILDDIR and optionally GABBLE_TEST_SLEEP in the
environment
* look for installed or uninstalled files, as appropriate
* use TEST_PYTHON (which might differ from PYTHON)
* use python -u (unbuffered stdout) for better debugging
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65290
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65290
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
|
|
We now depend on 2.32.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65290
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
|
|
In practice we depend on it anyway, via telepathy-glib 0.19.9.
Also update the telepathy-glib dependency in the .pc files to match
configure.ac.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65290
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
|
|
Conflicts:
NEWS
configure.ac
|
|
|
|
It has a race condition or something.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49595
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
libdbus is not thread-safe by default. This is a long-standing design
flaw (<https://bugs.freedesktop.org/show_bug.cgi?id=54972>).
We call into GIO, which calls into glib-networking, which can
(at least in recent versions) invoke libproxy in a thread. libproxy
apparently has a Network-Manager plugin, which uses libdbus in that
thread; meanwhile, we use libdbus in the main thread and everything
goes badly for us.
(It's possible that this crash is only reproducible with broken
connectivity: I wrote this patch on a train, with intermittent
mobile broadband coverage.)
In libdbus < 1.7.4, libraries cannot safely initialize libdbus for
multi-threading, because that initialization is not itself
thread-safe (!); in particular, glib-networking cannot safely initialize
libdbus. So, we have to do it.
I have written patches to make libdbus thread-safe-by-default, but
they haven't all been reviewed and merged yet, and in any case they
won't be in a stable libdbus until 1.8. Until then, each application
has to discover and fix this bug individually.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65296
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
|
|
|
|
It has a race condition or something.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49595
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
|
|
libdbus is not thread-safe by default. This is a long-standing design
flaw (<https://bugs.freedesktop.org/show_bug.cgi?id=54972>).
We call into GIO, which calls into glib-networking, which can
(at least in recent versions) invoke libproxy in a thread. libproxy
apparently has a Network-Manager plugin, which uses libdbus in that
thread; meanwhile, we use libdbus in the main thread and everything
goes badly for us.
(It's possible that this crash is only reproducible with broken
connectivity: I wrote this patch on a train, with intermittent
mobile broadband coverage.)
In libdbus < 1.7.4, libraries cannot safely initialize libdbus for
multi-threading, because that initialization is not itself
thread-safe (!); in particular, glib-networking cannot safely initialize
libdbus. So, we have to do it.
I have written patches to make libdbus thread-safe-by-default, but
they haven't all been reviewed and merged yet, and in any case they
won't be in a stable libdbus until 1.8. Until then, each application
has to discover and fix this bug individually.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65296
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
|
|
|