commit a8acc8177e476d5ef75ff3e2aa21d6ec0520c581
Author: Ondrej Holy <oholy@redhat.com>
Date:   2015-11-09

    Update NEWS for 1.26.2 release

M	NEWS

commit d7fc2c623b688661f94ac6d050e4077b9f84610e
Author: Aurimas Černius <aurisc4@gmail.com>
Date:	2015-11-06

    Fixed errors in Lithuanian translation

M	po/lt.po

commit ac80e77f6e45a3b688238e1fbf5b8baba98b58b4
Author: Simon McVittie <simon.mcvittie@collabora.co.uk>
Date:	2015-10-23

    Accept XDG_RUNTIME_DIR/bus as a valid D-Bus session/user bus

    These checks for DBUS_SESSION_BUS_ADDRESS were added to solve
    https://bugzilla.gnome.org/show_bug.cgi?id=526454,
    in which non-X11-session processes (for example a system service),
    or processes under su or similar inside an X11 session, could cause
    a dbus-daemon to be autolaunched via dbus-launch. If there was no
    X11 display to represent the lifetime of a session, the dbus-daemon
    would potentially run forever, causing a "leaked" process;
    additionally, other uses of D-Bus by the same uid would start more
    dbus-daemons.

    This becomes potentially problematic on systems with the "user bus"
    model introduced in dbus 1.10: libdbus, GDBus and sd-bus will now
    all try the per-uid socket XDG_RUNTIME_DIR/bus before attempting
    autolaunch, so if those are known to be the only implementations in
    use on a "legacy-free" system, setting DBUS_SESSION_BUS_ADDRESS is
    unnecessary. Check for that socket before giving up.

    XDG_RUNTIME_DIR/bus as implemented by dbus 1.10 with systemd avoids
    several of the down sides of autolaunching: it will never start more
    than one session bus per uid, and the socket and bus will
    automatically
    be cleaned up when the corresponding "systemd --user" exits.

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

M	client/gdaemonvfs.c
M	common/gvfsutils.c
M	common/gvfsutils.h
M	monitor/proxy/gproxyvolumemonitor.c

commit d236257299344207736086400960b0add2c1200b
Author: Ondrej Holy <oholy@redhat.com>
Date:	2015-10-19

    google: Fail in-fs copy/move if it leads to display name loss

    Complicated file name handling on google backend leads to display name
    loss if in-fs copy and move operation is proceeded e.g. using
    Nautilus.
    Proper fix will require larger changes for the whole
    platform. Therefore
    fail the job preferably to avoid display name loss...

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

M	daemon/gvfsbackendgoogle.c

commit cbd7bb86723d0cc7bd1b6564a9f60fad616a1771
Author: Debarshi Ray <debarshir@gnome.org>
Date:	2015-10-16

    proxy volume monitor: Properly handle failure to create a remote proxy

    We should finish constructing the innards of the object and not leave
    it in an inconsistent state when we hit an error. The other option
    would be to litter the rest of the code with NULL checks, but that
    would be ugly and prone to errors.

    We should also ensure that the reference counting stays consistent
    with
    the non-error paths.

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

M	monitor/proxy/gproxyvolumemonitor.c

commit 3aade766e1793bbf3ba2ecd29aba44d0467a0c6d
Author: Ondrej Holy <oholy@redhat.com>
Date:	2015-10-15

    google: Mark files you can't see on the web as hidden

    Files without the parent are currently shown in google backend root.
    You can see many files consequently, which are not shown in your
    google
    drive folder on the web. Those files can be shared with you, or you
    opened them in some google applications (i.e. google docs). Mark those
    files as hidden to see same files as you can see on the web. Also mark
    the files as undeletable, because it is not possible to delete them
    from the obvious reason.

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

M	daemon/gvfsbackendgoogle.c

commit e65c48683510f6a069628029bf07c15041af2074
Author: Ondrej Holy <oholy@redhat.com>
Date:	2015-10-15

    Post release version bump

M	configure.ac