summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* fd.o#22705: turn on both MC and tp-glib debug if MC_DEBUG=allSimon McVittie2009-09-101-2/+64
| | | | | Also put in basic support for MC having Gabble-style debug categories in future.
* mcd_debug_[un]ref: deprecate, and stop overriding g_object_[un]refSimon McVittie2009-09-103-43/+12
| | | | | | | | | | | | The output from these turns out not to be as useful as you might think: about half the refs and unrefs happen somewhere in the bowels of GObject (e.g. g_value_dup_object creates a ref without calling mcd_debug_ref), so the debug log, while verbose, doesn't actually provide enough information to locate leaks. refdbg is what I actually ended up using to find leaks during 5.1 development; it works considerably better in practice, and doesn't require source code modification (or namespace pollution).
* mc-server: use a TpDebugSender, to log everything over D-Bus if enabledSimon McVittie2009-09-101-0/+21
| | | | | | This isn't in the library, so other things that link libmissioncontrol-server (mainly osso-mission-control on Maemo) won't automatically have a TpDebugSender.
* with-session-bus.sh: fix bashism (&> doesn't work in dash)Simon McVittie2009-09-101-1/+1
|
* src: set a proper G_LOG_DOMAIN (mcd)Simon McVittie2009-09-101-0/+1
| | | | | | This will lead to log messages like: (process:12345): mcd-DEBUG: telepathy-mission-control version 5.2.3+
* Merge branch 'telepathy-mission-control-5.2'Simon McVittie2009-09-101-0/+19
|\ | | | | | | | | Conflicts: configure.ac
| * Post-release version bumpSimon McVittie2009-09-102-1/+6
| |
| * Prepare new bugfix releasetelepathy-mission-control-5.2.3Simon McVittie2009-09-102-1/+15
| |
* | Merge branch '52-try-more-handlers' into masterSimon McVittie2009-09-106-254/+336
|\ \ | | | | | | | | | | | | | | | Originally targeted for 5.2, but probably too risky there. Reviewed-by: Alberto Mardegan <alberto.mardegan@nokia.com>
| * | dispatcher/handle-channels-fails.py: assert that we try more than one handlerSimon McVittie2009-09-091-2/+32
| | |
| * | If HandleChannels fails, remember that the handler is broken and move on to ↵Simon McVittie2009-09-091-33/+43
| | | | | | | | | | | | | | | | | | | | | | | | the next one If there are no handlers we haven't tried, mcd_dispatcher_run_handlers will close the channels anyway, so there's no longer any need to close them in the HandleChannels callback.
| * | McdDispatcher: rename skip_approval to approved, and set it from more placesSimon McVittie2009-09-091-13/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of implicitly approving channels in the following situations, we now set the flag explicitly: - all approvers reject the channels (or, as a trivial case, no approver is run at all) - a handler exists that bypasses approval (this is not quite right, fd.o #23687, but preserves existing behaviour) - a CDO finishes - the channel has Requested=TRUE to start with
| * | _mcd_dispatcher_enter_state_machine: don't short-cut to running clients if ↵Simon McVittie2009-09-091-14/+4
| | | | | | | | | | | | | | | | | | | | | there are no filters If there are no filters, mcd_dispatcher_context_proceed will run the clients anyway, so we might as well reduce the number of code paths.
| * | _mcd_dispatcher_enter_state_machine: use mcd_dispatcher_context_proceed ↵Simon McVittie2009-09-091-1/+1
| | | | | | | | | | | | | | | | | | | | | instead of the equivalent call to mcd_dispatcher_context_process _process's semantics are less obvious and it will be deprecated eventually.
| * | Correct a commentSimon McVittie2009-09-091-1/+1
| | |
| * | McdDispatchOperation: change _mcd_dispatch_operation_handle_with to ↵Simon McVittie2009-09-083-27/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _mcd_dispatch_operation_approve It's only called from outside McdDispatchOperation in order to say "handling with any handler is acceptable" (because a request constitutes approval), never to say "handle with this specific handler". It also doesn't need to return the error, because the only possible error is NotYours, which the caller ignores anyway.
| * | Remove McdDispatchOperation from public API/ABISimon McVittie2009-09-085-110/+79
| | |
| * | McdDispatchOperation: factor out mcd_dispatch_operation_check_handle_with ↵Simon McVittie2009-09-081-13/+36
| | | | | | | | | | | | (the checks that can be done synchronously)
| * | McdDispatcherContext: always release all client locks, and use a separate ↵Simon McVittie2009-09-081-22/+17
| | | | | | | | | | | | | | | | | | flag to suppress handlers This makes the handling of CTXREF14 more obviously correct.
| * | Replace McdDispatcherContext->client_locks with a booleanSimon McVittie2009-09-081-19/+9
| | | | | | | | | | | | It only has one use, now.
| * | McdDispatcherContext: replace the troublesome CTXREF13 with a ref held ↵Simon McVittie2009-09-081-12/+18
| | | | | | | | | | | | | | | | | | | | | exactly when we're awaiting approval This is more obviously correct; previously, it wasn't at all clear that the refcounting worked correctly.
| * | McdDispatcherContext: ref the context for the duration of on_operation_finishedSimon McVittie2009-09-081-1/+8
| | |
| * | Improve comments that explain how client locks workSimon McVittie2009-09-081-6/+12
| | |
| * | McdDispatcherContext: separate pending approvers out from client_locks into ↵Simon McVittie2009-09-081-25/+41
| | | | | | | | | | | | awaiting_approval and approvers_pending
| * | McdDispatcherContext: separate pending observers from other "client locks"Simon McVittie2009-09-081-12/+31
| | |
* | | Merge branch 'telepathy-mission-control-5.2'Simon McVittie2009-09-107-82/+13
|\ \ \ | | |/ | |/| | | | | | | Conflicts: configure.ac
| * | Merge branch '52-trivia' into telepathy-mission-control-5.2Simon McVittie2009-09-107-82/+13
| |\ \ | | |/ | |/| | | | Reviewed-by: Alberto Mardegan <alberto.mardegan@nokia.com>
| | * Don't distribute generated sources in tarballSimon McVittie2009-09-091-10/+6
| | |
| | * Distribute assorted files that are present in git but not in tarballsSimon McVittie2009-09-092-0/+3
| | |
| | * Remove src/mcd-main.cSimon McVittie2009-09-092-52/+0
| | | | | | | | | | | | | | | It's not compiled (server/mc-server.c is the real daemon), and not distributed in tarballs.
| | * Remove unused mcd-filtering-int.h from gitSimon McVittie2009-09-092-19/+1
| | | | | | | | | | | | It's not distributed in tarballs, or compiled.
| | * fd.o #23807: distribute mc-account-convert.1 in tarballs even if gconf was ↵Simon McVittie2009-09-091-1/+3
| |/ | | | | | | | | | | | | not available at configure time Otherwise, people who have gconf headers can't compile tarballs produced by people who don't have gconf headers.
| * Post-release version bumpSimon McVittie2009-09-071-1/+1
| |
* | Merge commit 'telepathy-mission-control-5.2.2'Simon McVittie2009-09-0715-47/+323
|\ \ | |/ | | | | | | Conflicts: configure.ac
| * Prepare stable release 5.2.2telepathy-mission-control-5.2.2Simon McVittie2009-09-072-1/+29
| |
| * Merge branches '52-permissions' and '52-tubes' into ↵Simon McVittie2009-09-077-18/+85
| |\ | | | | | | | | | | | | | | | telepathy-mission-control-5.2 Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
| | * Factor out identical "should I close it?" logic from _mcd_channel_close, ↵Simon McVittie2009-09-071-32/+24
| | | | | | | | | | | | _mcd_channel_undispatchable
| | * _mcd_channel_close: don't close old Tubes channelsSimon McVittie2009-09-071-2/+10
| | |
| | * Don't close Tubes channels if undispatchableSimon McVittie2009-09-071-0/+6
| | | | | | | | | | | | This implicitly closes every Tube in the channel too, which isn't useful.
| | * McdChannel: improve debug when not closing an undispatchable channelSimon McVittie2009-09-071-6/+17
| | |
| | * fd.o#23778: fix permissions of any existing account storage with ↵Simon McVittie2009-09-072-2/+5
| | | | | | | | | | | | _mcd_chmod_private, and don't use 0777 permissions to start with
| | * mcd-misc: add _mcd_chmod_private()Simon McVittie2009-09-072-0/+33
| | |
| | * McdMaster: if umask is available, create dirs/files with 0700/0600 permissionsSimon McVittie2009-09-071-0/+12
| | |
| | * configure.ac: check for umask and its headersSimon McVittie2009-09-071-0/+2
| | |
| * | Merge branch '52-pre-presence' into telepathy-mission-control-5.2Simon McVittie2009-09-077-29/+210
| |\ \ | | |/ | |/| | | | Reviewed-by: Alberto Mardegan <alberto.mardegan@nokia.com>
| | * auto-connect: be less strict about ordering of eventsSimon McVittie2009-09-031-6/+5
| | | | | | | | | | | | | | | | | | Now that we "pre-load" presence, CurrentPresence can change sooner; so, don't expect the signal (it can happen at basically any time), but just do a Get for the property at the end.
| | * dispatcher/already-has-*.py: succeed despite early GetInterfaces callSimon McVittie2009-09-033-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These tests make assumptions about the order of method calls in order to set up unusual situations, so the early call to GetInterfaces made them deadlock. Also take the opportunity to exercise the code path in which GetInterfaces fails before the connection goes CONNECTED, emulating a telepathy-glib 0.7.35 (or older) CM.
| | * account-manager/presence.py: assert that we try to set presence before Connect()Simon McVittie2009-09-031-9/+39
| | |
| | * mctest: allow expecting events before Connect()Simon McVittie2009-09-031-2/+7
| | |
| | * mctest: simulate SimplePresence more accuratelySimon McVittie2009-09-031-7/+18
| | |
View Lorry Controller Status