updates for TODO and README

* library support for setns() system call was added to glibc
version 2.14 (setns() call is use in src/machine/machinectl.c
and src/libsystemd-bus-container.c)

* utf8 validation call are already exported (via sd-utf8.c file) -
commit - 369c583b3fb3d672ef469d53141e274ec9d2e8a7
TODO: remove dbus requirement
networkd: Initialize variable to NULL

If any number of arguments are given, _cleanup_manager_free_ is used
with unitialized memory causing a crash.
TODO: add dbus runtime depedency
service: add the ability for units to join other unit's PrivateNetwork= and PrivateTmp= namespaces
bus: properly handle if we get disconnected during HELLO phase
namespace: comment typo fix
Revert "socket-proxyd: Add --listener option for listener/destination pairs."

This reverts commit adcf4c81c58511b67644e17fa743d1729d3c9ccf.

We have a better solution for the problem of making two processes run in
the same namespace, and --listener is not needed hence and should be
dropped.

Conflicts:
	man/systemd-socket-proxyd.xml
TODO: add sd-rtnl items
core: initialize variable
automount: log info about triggering process
bus: update kdbus.h and always subscribe to KDBUS_HELLO_ATTACH_NAMES
catalog: fix typos in the French translation
catalog,po: add Russian translation
po: install translations
build-sys: avoid warnings from assert_cc
login: revert lazy session-activation on non-VT seats

Existing applications like gdm already depend on new sessions to get
immediately activated on seats without VTs. Fixes a bug reported as:
  [systemd-devel] systemd 208:trouble with inactive user sessions at non-seat0 seats

This patch restores the original behavior. We either need to add a new
flag for session-creation or some other heuristic to avoid activating new
sessions in the future.
bus: add bus_name_has_owner() helper

Small helper to run a synchronous "NameHasOwner" request on the
dbus-daemon.
logind: ignore failing close() on session-devices

Unfortunately, close() on a revoked/removed character-device fails with
ENODEV. I tried tracking this down in the kernel, but couldn't figure out
were exactly it comes from. However, can be easily reproduced with:
  fd = open("/dev/input/event0", O_RDWR);
  ioctl(fd, EVIOCREVOKE, 0);
  r = close(fd);
A second close on @fd would return EBADF so the close is actually valid.

We simply ignore close() errors for all session-devices as their access
may be revoked asynchronously, or the device might get unplugged.
We use close_nointr() in case anyone ever looks at the return value (or
anyone runs "grep 'close(' -r src/" to find broken close() calls).

Fixes:
  systemd-logind[31992]: Assertion 'close_nointr(fd) == 0' failed at src/shared/util.c:185, function close_nointr_nofail(). Aborting.
logind: restore session-controller after crash

We now save the unique bus-name of a session-controller as CONTROLLER=%s
in the session files. This allows us to restore the controller after a
crash or restart.

Note that we test whether the name is still valid (dbus guarantees that
the name is unique as long as the machine is up and running). If it is,
we know that the controller still exists and can safely restore it. Our
dbus-name-tracking guarantees that we're notified once it exits.

Also note that session-devices are *not* restored. We have no way to know
which devices where used before the crash. We could store all these on
disk, too, or mark them via udev. However, this seems to be rather
cumbersome. Instead, we expect controllers to listen for NewSession
signals for their own session. This is sent on session_load() and they can
then re-request all devices.

The only race I could find is if logind crashes, then the session
controller tries calling ReleaseControl() (which will fail as logind is
down) but keeps the bus-connection valid for other independent requests.
If logind is restarted, it will restore the old controller and thus block
the session.
However, this seems unlikely for several reasons:
 - The ReleaseControl() call must occur exactly in the timespan where
   logind is dead.
 - A process which calls ReleaseControl() usually closes the
   bus-connection afterwards. Especially if ReleaseControl() fails, the
   process should notice that something is wrong and close the bus.
 - A process calling ReleaseControl() usually exits afterwards. There may
   be any cleanup pending, but other than that, usual compositors exit.
 - If a session-controller calls ReleaseControl(), a session is usually
   considered closing. There is no known use-case where we hand-over
   session-control in a single session. So we don't care whether the
   controller is locked afterwards.

So this seems negligible.