Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
|
|
|
|
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>
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65131
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
|
|
|
|
|
|
|
|
Reviewed-by: Xavier Claessens <xavier.claessens@collabora.co.uk>
|
|
Conflicts:
NEWS
configure.ac
lib/ext/wocky
|
|
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65036
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
|
|
We don't currently use JabberAuthenticator in this mode, so nobody
noticed that it didn't work. I'm about to add a test that does use it.
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65036
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
[added CVE ID now that we have one -smcv]
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65036
|
|
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=64354
|
|
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=64319
|
|
|
|
We also have local changes, which should go "upstream" to telepathy-glib
at some point.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63119
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
NEWS
configure.ac
lib/ext/wocky
|
|
|
|
|
|
|
|
|
|
|
|
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43166#c0
|
|
This didn't work as-is because the <presence type='unavailable'> had no
<x> child. Using make_muc_presence() does the job nicely.
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=43166#c7
|
|
There were a combination of problems before:
* The server's error message was not exposed in the delivery report;
* Wocky didn't recognise policy-violation;
* There was a bug in Wocky's error parsing code which clobbered the
message type.
So many bugs for such a small stanza!
|