Hi from im-config maintainer.
> Osamu Aoki
>im-config
On Sun, Aug 28, 2016 at 02:59:13PM +0100, Simon McVittie wrote:
> I'm about to do a mass-bug-filing against packages that mention
> dbus-x11 in their dependencies, or dbus-launch in their code, asking
> maintainers to adjust their depende
At first, I thought it's a random set of words. Then I noticed that they
follow language rules and thought that it's a nicely crafted Markov chain
text designed to look like random babbling of a typical systemd-hater. It
looks like I was wrong after all.
--
WBR, wRAR
signature.asc
Description:
uters can be had for
$50-$200, hanging terminals makes little economic sense. I'm sure the
systemd afficianados will find such a use case, and proclaim that use
case must be served, but we all know it's FUD.
The systemd folks shout from the mountaintops that sysvinit is 32 years
old
On Sun, 04 Sep 2016 at 17:30:43 +0100, Jonathan de Boyne Pollard wrote:
> Simon McVittie:
> > To the best of my knowledge, the listenable address "unix:runtime=yes"
> > (as in "dbus-daemon --address=unix:runtime=yes") does work on generic
> > Unix, and should interoperate fine with the XDG_RUNTIME_
On Sun, 04 Sep 2016 at 19:24:09 +0100, Jonathan de Boyne Pollard wrote:
> You think that a good "replacement directory" is /run/user/$EUID . Alright.
> Then when your program is told address=unix:runtime=yes and there's no
> XDG_RUNTIME_DIR, please make it fall back to using the directory that you
XDG Base Directory Specification:
If $XDG_RUNTIME_DIR is not set applications should fall back to a
replacement directory with similar capabilities and print a warning
message
Simon McVittie:
Are you saying that if XDG_RUNTIME_DIR is not set, D-Bus client
libraries should choose some arbit
Simon McVittie:
This can already work. If you put XDG_RUNTIME_DIR in user programs'
environment, and arrange for your favourite service manager to make a
dbus-daemon (or something else that speaks the same protocol) listen
on $XDG_RUNTIME_DIR/bus before any user process would try to connect
t
On Mon, 29 Aug 2016 at 15:49:55 +0100, Jonathan de Boyne Pollard wrote:
> One can run PCDMd,
> kdm, gdm, and lxdm under nosh service management, and it would be good for the
> programs in the login session(s) to just expect "/run/user/$UID/..." sockets,
> as one already obtains from running "user"
In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon
McVittie:
Please contact the D-Bus upstream mailing list if you are interested
in implementing a user bus without systemd. You will need something
resembling pam_xdg_support (which is what Ubuntu used before they
switched t
I'm about to do a mass-bug-filing against packages that mention
dbus-x11 in their dependencies, or dbus-launch in their code, asking
maintainers to adjust their dependencies to make dbus-x11 optional.
My goal is that users can install the major desktop tasks in stretch
(GNOME, KDE, etc.) with eithe
On Thu, 2016-07-28 at 15:25 +0100, Simon McVittie wrote:
> On Thu, 28 Jul 2016 at 08:33:21 -0400, Marvin Renich wrote:
> > Do you mean metapackage or virtual package? Wouldn't a virtual
> > package
> > be exactly the right thing for this? Then dbus-user-session and
> > dbus-x11 would each "Provid
On Thu, 28 Jul 2016 at 08:33:21 -0400, Marvin Renich wrote:
> * Simon McVittie [160727 20:04]:
> > On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote:
> > > Shouldn't this
> > > dependency only be declared at some other level (libdbus, GDBus,...)?
> >
> > I think this would have to b
Simon McVittie wrote:
> On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote:
>
> > If the package name is changing or if we are dropping dbus-x11 in
the future
> > that would require modifying again quite some packages.
>
> I currently count 55 direct Depends and 17 Recommends on db
* Simon McVittie [160727 20:04]:
> On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote:
> > Shouldn't this
> > dependency only be declared at some other level (libdbus, GDBus,...)?
>
> I think this would have to be a new dbus-session metapackage, unless
> I'm missing something. dbus i
Simon McVittie wrote:
> On Wed, 27 Jul 2016 at 23:48:42 -0700, Josh Triplett wrote:
> > I can think of another reason that this might change: if we introduce an
> > (experimental, and eventually non-experimental) variant based on a
> > future stable version of kdbus.
>
> The usual difficulties of d
On 2016-07-28 01:03:04 +0100, Simon McVittie wrote:
> libdbus-1-3 shouldn't depend on a session bus, because you might only
> be using it to access the system bus;
Or because the user might not use the system bus at all, but the
application depends on libdbus-1-3 it because it's a library and
uses
On Wed, 27 Jul 2016 at 23:48:42 -0700, Josh Triplett wrote:
> I can think of another reason that this might change: if we introduce an
> (experimental, and eventually non-experimental) variant based on a
> future stable version of kdbus.
The usual difficulties of depending on kernel features aside
Simon McVittie wrote:
> On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote:
> > Is that really up-to the individual application to declare a
> > dependency
> > against dbus-user-session | dbus-x11 ?
>
> At the moment: yes. A dependency on dbus-x11 (in jessie) or on
> dbus-user-session
On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote:
> Is that really up-to the individual application to declare a dependency
> against dbus-user-session | dbus-x11 ?
At the moment: yes. A dependency on dbus-x11 (in jessie) or on
dbus-user-session | dbus-x11 (now) can be used to signi
Simon McVittie wrote:
Hi,
Recommendations for other software that relies on D-Bus
===
This recommendation applies to ordinary apps that rely on having a
session bus but are not a core part of a desktop environment, such as
the Empathy real-ti
I'm planning to do a mass-bug-filing against packages that mention
dbus-x11 in their dependencies, or dbus-launch in their code, asking
maintainers to adjust their dependencies to make dbus-x11 optional.
My goal is that users can install the major desktop tasks in stretch
(GNOME, KDE, etc.) with ei
21 matches
Mail list logo
