[bts-link] source package systemd

# # bts-link upstream status pull for source package systemd # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #837183 (http://bugs.debian.org/837183) # Bug title: systemd: unprivileged call to

Bug#732209: dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.

On Thu, Sep 15, 2016 at 6:45 AM, Vlad Orlov wrote: > > > Is su actually used for running graphical apps? In my case, I either accidentally typed into an su window, or possibly ran the gconf editor as root, for some possibly good or bad reason, possibly having to do with xdm,

Bug#837759: network configuration stops working reliably

On 14 September 2016 at 18:34, Wolfgang Walter wrote: > On Wednesday, 14 September 2016 10:00:28 CEST Felipe Sateler wrote: >> Control: tags -1 moreinfo >> >> On 14 September 2016 at 06:59, Wolfgang Walter >> wrote: >> > Package: systemd >> >

Bug#732209: dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.

Hi, Just found a link to a pam module [1] (posted in the comment at [2]). > It's a pam module that removes the XDG_RUNTIME_DIR environment variable from > the environment if the user authenticating is different from the user owning > it. This is for the case of programs like gksu clobbering the

Bug#732209: dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.

Hi, Is su actually used for running graphical apps? Most people seem to use gksu for that. But gksu --help shows a weird warning about using -l argument: --login, -l Make this a login shell. Beware this may cause problems with the Xauthority magic. Run xhost to allow the target

Bug#837893: systemd: Logging from gnome session is passed on to all syslog facilities

Package: systemd Version: 231-6 Severity: normal Since recently, log messages from programs running under the gnome session have started appearing in all logs in /var/logs, including /var/logs/kern.log, even though my rsyslog configuration has not changed, and correctly only routes kern.* there.