On 25/02/14 17:30, Kay Sievers wrote:
There is not real difference, everything is just a message, being a
signal or a method. Only signals are limited to pure copied data,
disallowing fds; therefore signals will not be suitable for really
large data.
D-Bus allows unicast signals (libdbus API:
On 04/03/14 11:00, Umut Tezduyar wrote:
Stable version of some distros (Debian Wheezy nor Ubuntu LTS 12.04)
still don't have support for this.
Does that actually matter much? This ln usage is at build time, not
install time, and those stable versions aren't going to upgrade to a
current
On 18/05/14 16:47, Cristian Rodríguez wrote:
OK, Let's try [building everything -fPIE] instead.
Hopefully things have improved since 2011, but my experience with
dbus[1] has been that this works fine on mainstream architectures, but
frequently fails on embedded architectures (arm* family, mips*
On 01/06/14 20:03, Mantas Mikulėnas wrote:
Out of curiosity, wouldn't the existing
org.freedesktop.DBus.Peer.GetMachineId() work here?
In principle Peer.GetMachineId() returns the D-Bus machine ID
/var/lib/dbus/machine-id, which in rare cases won't match the systemd
machine ID /etc/machine-id,
On 10/06/14 18:58, Mike Gilbert wrote:
The problem with installing these symlinks as part of a package is
that the user may have removed them from /etc/systemd using systemctl
disable.
...
If rpm or dpkg have a way to detect when the sysadmin has removed a
file and will not replace that file,
On 23/06/14 20:09, Vasiliy Tolstov wrote:
Because now with avahi i can't
publish additional addresses and need to patch sources to minimize
timeout from 5000msec to 1000msec. (my hosts does not have ptr
records and for each ping i have 5 sec timeout =()
It sounds as though you have a
On 24/06/14 07:15, Vasiliy Tolstov wrote:
_minimal have bugs and very ugly code.
For example it send multicast only via first interface that up.
Are you confusing libnss_mdns*_minimal.so (which refuse to resolve names
outside .local and addresses outside the link-local range) with
./configure
On 30/06/14 20:56, Filipe Brandenburger wrote:
On Mon, Jun 30, 2014 at 12:28 PM, Kay Sievers k...@vrfy.org wrote:
We should find out when we need to create /lib64 -- $libdir, grr ... :)
Consider the case where you're running Fedora but use debootstrap to
create a Debian tree and
On 03/07/14 12:09, Lennart Poettering wrote:
32bit ARM (yay, at least 4 ABIs to choose from, well done!)
The current status quo in Debian and its derivatives seems to be when
introducing a new ARM flavour, the ARM and toolchain people argue about
its canonical name for a while. There
On 04/07/14 11:33, Lennart Poettering wrote:
~/.config: state and configuration, the counterpart for both /etc/ *and*
/var/lib/ in the home directory
~/.local: static vendor resources of additional packages installed into
the home directory. Should be considered
On 03/07/14 14:27, Lennart Poettering wrote:
BTW, to clarify what this is about I will now rename the tupel macro
from ARCH_TUPLE to LIB_ARCH_TUPLE or so, since this is about locations
for shared libraries, nothing else.
Please consider calling it something with MULTIARCH in if you're using
On 06/07/14 20:38, Lennart Poettering wrote:
Our understanding so far was more that multilib refers to the scheme
which allows you to run executables of different, but compatible archs
on the same system. In this scheme you would have your each executable
only of one arch around, but you can
On 31/07/14 21:38, Kay Sievers wrote:
We have one .busname file per name and it will get really complicated
to start stop a busname, when it has multiple names per connection. We
should really avoid that and require one connection per name and allow
only name.
I might be misunderstanding what
On 01/08/14 12:20, Kay Sievers wrote:
On Fri, Aug 1, 2014 at 1:13 PM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
are you saying that under kdbus, each connection to the bus [...] is only
allowed to own one well-known name (thing like org.freedesktop.systemd1)?
No, it is not about
at
the very top of every .c file, whether it is currently needed or not.
Thanks for reminding me to upstream this!
S
From 669af691816ee56dbf097ae7f0e4f207af5929f5 Mon Sep 17 00:00:00 2001
From: Simon McVittie simon.mcvit...@collabora.co.uk
Date: Tue, 29 Jul 2014 14:40:18 +0100
Subject: [PATCH
On 07/08/14 12:23, Peter Mattern wrote:
If one of these options gets stated more than once the different
instances seem to be linked by a logical AND, too.
Yes. This is documented in systemd.unit(5), which also describes how a
drop-in can reset the list of conditions and start from a clean
On 07/08/14 15:21, Dimitri John Ledkov wrote:
tmpfiles.d files do not depend on /usr present, and in
--enable-split-usr configuration there may be system units
(e.g. shipped in /lib) that rely on tmpfiles.d to be configured
e.g. tmpfiles.d/systemd.conf itself. Hence tmpfiles.d should use
._AudioQuest_DragonFly
...
device.profile.name = analog-stereo
device.profile.description = Analog Stereo
device.description = Integrated Rate Matching Hub Analog
Stereo
From e0bb1d9cf82e397b08335e5d7107a8506849e823 Mon Sep 17 00:00:00 2001
From: Simon McVittie
On 14/08/14 13:27, Vlad Orlov wrote:
### BEGIN INIT INFO
# Provides: mintsystem
# Required-Start:$local_fs $syslog $remote_fs dbus
# Required-Stop: $local_fs $syslog $remote_fs
# Default-Start: S
# Default-Stop:
### END INIT INFO
As Lennart said, this is
On 14/08/14 14:31, Simon McVittie wrote:
Default-Start: S means basic-target.target depends on
mintsystem.service, which depends on dbus.service, which does not have
DefaultDependencies=no, so it implicitly depends on sysinit.target, so
you lose.
Sorry, that's not quite right. Default-Start
On 14/08/14 16:04, Zbigniew Jędrzejewski-Szmek wrote:
Actually, most of them probably don't need to run at all:
Many of the ones you quoted indeed don't make sense with systemd and are
either explicitly masked by a symlink to /dev/null, or have a
corresponding native systemd service that
On 14/08/14 16:29, Lennart Poettering wrote:
On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
systemd: Copy rules generated while the root was ro
Hmm, wut? What's that supposed to be?
I think it's glue for running udev when pid 1 != systemd and there was
no
On 20/08/14 16:28, Tom Gundersen wrote:
+int attach_sd_event_to_g_main_loop(GMainLoop *loop, sd_event *event) {
(I know this is only a proof of concept but)
I think the construct you're looking for is a GMainContext, not a GMainLoop:
https://tecnocode.co.uk/2014/03/27/what-is-gmaincontext/
On 21/08/14 19:12, Ivan Shapovalov wrote:
Actually, I don't pretty understand the reasoning behind skipping the default
dependencies on /usr mount
(Some of) the default dependencies require that /usr is mounted, so
mounting /usr cannot depend on them, to avoid a cycle.
(Or to put it the way
On 30/07/13 00:02, Lennart Poettering wrote:
Also, D-Bus needs to look for the bus socket in $XDG_RUNTIME_DIR too.
If you want this to happen (you in general, but especially Lennart who
is a D-Bus reviewer), please review, test and/or adopt
https://bugs.freedesktop.org/show_bug.cgi?id=61303. I
On 04/08/13 15:46, Colin Walters wrote:
1) Pretty much all the user processes are no longer inside a session
at all.
2) It is now much harder to log in multiple times graphically; this
is kind of a crazy thing to do, but it's still *possible*.
How (if at all) does this cope with gdm
On 04/11/13 14:42, Lennart Poettering wrote:
A lot of (library)
code is not happy with being initialized in one process and being
used in another forked off one.
For what it's worth, fork(3posix) also notes this:
* A process shall be created with a single thread. If a multi-threaded
process
On 13/11/13 12:24, David Timothy Strauss wrote:
Based on the autotools docs, it looks like this would change the
default to enabled maintainer mode, meaning developers would need to
run --disable-maintainer-mode to maintain the current behavior. Is
this correct?
Absence of AM_MAINTAINER_MODE
On 05/12/13 12:13, Lukasz Skalski wrote:
destination - the unique bus name for the destination for the signal
or NULL to emit to all listeners.
This is rarely-needed functionality, but sometimes necessary. If anyone
is going to replicate the client-facing functionality of the dbus-daemon
using
On 12/12/13 14:28, Lennart Poettering wrote:
kay and Daniel are working on changing the semantics of monitoring
entirely. Instead of turning monitoring on and off on an existing
connection they want this to be an entirely new connection type
Colin Walters wanted to do this in dbus-daemon too
On 17/12/13 20:19, Lennart Poettering wrote:
Hmm, D-Bus and glib both try to be compatible with various older
systems, so connecting to /var/run appears to be the safe choice.
That said, I am pretty sure it would be a good idea to patch make them
avoid /var/run on systems where that's just
On 16/01/14 15:41, Lennart Poettering wrote:
There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun,
On 17/01/14 09:42, Kay Sievers wrote:
This year will bring huge flag day compat breaks. We will drop all old
D-Bus support, we will require on a bleeding edge kernel, and so on.
Flag-day compatibility breaks are a massive pain for distributions. The
more things need to be upgraded in lockstep,
On 20/01/14 17:08, Lennart Poettering wrote:
On Mon, 20.01.14 17:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
Anyway, I don't see why using gold would be bad.
Good question. I have no experience with gold, but it's commonly
available these days, right?
Sort of;
I've recently been researching systemd's current support for user
sessions, with the goal of sorting out any remaining omissions/issues
and having GDM integrate well with it.
It looks as though the intention is that if I have overlapping sessions
like this:
* 14:00: log in to GDM on X11 display
On 18/02/13 19:08, Kok, Auke-jan H wrote:
On Mon, Feb 18, 2013 at 4:38 AM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
It looks as though the intention is [...]
I have one XDG_RUNTIME_DIR, one 'systemd
--user' instance (as per systemd's TODO: started by logind using
user@.service
On 18/02/13 20:13, Simon McVittie wrote:
Is there any plan for how GUI processes started via session D-Bus
activation should pick up the right value for $DISPLAY?
I've started prototyping what would be needed for `systemd --user` to
track logind sessions, pick up the new $DISPLAY every time
On 19/02/13 18:59, Kok, Auke-jan H wrote:
We may have to redefine systemd --user to start with a instance that
defines a user - seat pair instead. That would leave multiple
`systemd --user` pairs around, each serving the appropriate desktop.
They could use a central DBus location if needed,
On 19/02/13 23:55, Peeters Simon wrote:
or just use a systemd generater to generate systemd .service files from the
dbus service files.
(i have something like this laying around slightly unfinished if you
want code, let me know)
That would be an interesting way to avoid having to either patch
On 19/02/13 16:06, Simon McVittie wrote:
On 18/02/13 20:13, Simon McVittie wrote:
Is there any plan for how GUI processes started via session D-Bus
activation should pick up the right value for $DISPLAY?
I've started prototyping what would be needed for `systemd --user` to
track logind
On 04/03/13 14:31, Lennart Poettering wrote:
So here's how to do this, it's very simple: every char outside of the
A-Za-z0-9 range is escaped as _XY where XY is the numeric code of the
char, as 2 char lower-case hex value. Note that _ itself is also
escaped, to _5f.
This sounds a lot like
On 05/03/13 20:10, Lennart Poettering wrote:
Well, D-Bus would need to learn about this new [user] bus, and determine the
socket in $XDG_RUNTIME_DIR automatically, and also fallback from the
session to the user bus if the session bus is not reachable otherwise...
Do you really want to support
On 05/03/13 21:03, Lennart Poettering wrote:
My general suggestion is that applications should generally die if their
display goes away (libX11 already enforces this...).
Right, but that only happens for GUI applications. One of the original
rationales for D-Bus was that it was a way to avoid
On 05/03/13 21:23, Lennart Poettering wrote:
Kay actually wants to get rid of
the session bus entirely. My own idea was to use it only for gdm to
support the multi-seat case, where the same gdm user might need to run
multiple gdm sessions in parallel, one for each display. However, that
idea
On 16/03/13 15:10, Cedric BAIL wrote:
I think I am a little bit late about integrating systemd user
session in a desktop
Not really; as far as I can see, non-trivial systemd user sessions under
X11 need some more thought, and some more code.
Specifically, they need at least a change to
On 20/03/13 22:35, Lennart Poettering wrote:
kdbus is a new kernel implementation of D-Bus that Kay and Greg have
been working on.
Please talk to the D-Bus maintainers about any reimplementations or
replacements for D-Bus; we are on d...@lists.freedesktop.org.
(Cross-posted.)
Which parts of
On 25/03/13 13:28, Greg KH wrote:
The ideas only, the wire protocol is quite different, and in reality,
unknown as it isn't implemented yet, so all of your questions are a bit
premature, sorry.
Sure. When you have (proposed) answers to these questions, please talk
to the D-Bus maintainers
On 17/04/13 16:57, Lennart Poettering wrote:
Hmm, or maybe like this: enter the container, allocate a pty,
instantiate getty@.service for that pty, pass pty fd back to host, exit
in namespace, and process pty on the host as long as we don't get EOF.
This is probably a good idea for interactive
On 17/04/13 17:25, Kay Sievers wrote:
On Wed, Apr 17, 2013 at 6:08 PM, Henrik Grindal Bakken h...@ifi.uio.no
wrote:
ExecContext isn't used in this header file, and everything seems to
build just fine without this typedef. The typedef doesn't really belong
here, and at least my gcc-4.4.6
On 26/04/13 18:49, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 26, 2013 at 06:40:08PM +0200, Daniel Buch wrote:
-void* hashmap_get(Hashmap *h, const void *key);
-void* hashmap_get2(Hashmap *h, const void *key, void **rkey);
+void *hashmap_get(Hashmap *h, const void *key);
+void
On 03/05/13 13:16, Lennart Poettering wrote:
On Fri, 03.05.13 04:51, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
Hm, one of our tests fails because /usr/lib/systemd/system/auditd.service
is -rw-r-. That's crazy. Do we fight it, or work around it?
I'd say fight it. After all
in case you missed the initial mail:
http://lists.freedesktop.org/archives/dbus/2011-August/014617.html
Message-ID: 20110811180622.ga29...@reptile.pseudorandom.co.uk
On Thu, 11 Aug 2011 at 19:06:22 +0100, Simon McVittie wrote:
Current systemd/D-Bus integration (Fedora 15
On 04/09/14 23:32, Dale R. Worley wrote:
I admit that I haven't studied systemd enough to understand the
significance of WantedBy. My understanding is that systemd performs a
series of units, with dependencies showing which units must finish
before other units start.
Sort of. It has a goal
On 05/09/14 18:22, Jakub Klinkovský wrote:
What is the reason behind logging unit's description? Consider the
following journal message (from `journalctl -b`):
systemd[1]: Starting A secure, fast, compliant and very flexible
web-server...
As a data point, Debian's init scripts have
On 09/09/14 16:01, Colin Guthrie wrote:
On Mageia and Fedora (at least originally, not sure if it's changed
recently), the modules are in:
/lib/modules/kernel-version/
tree.
...
The actual modules are stored in a:
/lib/modules/kernel-version/kernel/
subfolder.
It's the same on Debian and
On 10/09/14 15:03, Michal Witanowski wrote:
I was wondering if there is a possibility to call “systemctl poweroff”
as non-root user [without PolicyKit or sudo]
...
Theoretically there is no other way, am I right?
If you want to escalate privileges in a controlled way, you need a
controlled
On 10/09/14 16:10, Simon McVittie wrote:
If you want to escalate privileges in a controlled way, you need a
controlled privilege-escalation tool. PolicyKit is one such tool;
systemctl is another; a setuid binary written by you [...]
is another possibility.
Sorry, that should read sudo
On 12/09/14 09:57, lux-integ wrote:
The question is; is there a way of conditionally procesing lines in systemd
service files such as the following
ExecStart=/path/to/executible1
ExecStart=/path/to/executible2
some condition satisfied ( for example ConditionFileNotEmpty=SomeFile
On 19/09/14 09:05, David Herrmann wrote:
-fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+r = fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
+if (r 0) {
+log_error(Failed to set pipe buffer size: %m);
+return -errno;
+}
I don't
On 22/09/14 10:27, Jan Synacek wrote:
If /etc/machine-id is missing on the system, the first open() call
should probably handle that case. That's actually not true (at least on
my system), because the underlying filesystem is read-only at that
time.
*What* is not true on your system?
Are you
On 22/09/14 10:23, Reindl Harald wrote:
honestly the messages about reaching target are nonsense without
a prefix pointing out that it is about a *user session* because it
looks like a bootlog every minute
You can tell this is not the system instance of systemd (init) because
its process ID
(Cc'd to the systemd mailing list because sd-bus is the reference
implementation of the user-space side of kdbus, but please join the dbus
list and follow-up there if you are interested in D-Bus.)
I've recently been looking at kdbus as a transport for D-Bus messages,
and how compatible or
---
src/libsystemd/sd-bus/PORTING-DBUS1 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1
b/src/libsystemd/sd-bus/PORTING-DBUS1
index 958e7b6..81e9413 100644
--- a/src/libsystemd/sd-bus/PORTING-DBUS1
+++ b/src/libsystemd/sd-bus/PORTING-DBUS1
D-Bus' type hierarchy as described in the spec is:
\- basic
\- fixed type (u, i, etc.)
\- string-like type (s, o, g)
\- container
Someone seems to have referred to basic types as simple types at
some point, but that term isn't defined in the D-Bus Specification,
and seems redundant.
So
On 02/10/14 10:09, Miroslav Suchy wrote:
If I want to become specific user inside of that container, I have to do
something like:
/usr/bin/systemd-nspawn -D foo /bin/su -l mockbuild -c 'rpmbuild -root
\'/build\' ...'
which quickly go into escape-hell.
If you put a better
On 25/09/14 22:12, Gustavo Sverzut Barbieri wrote:
move each user/group creation to a file that represents its own split
package, so it's possible to ship them in separate.
Even if you split out bits of systemd functionality like networkd,
timesyncd, kdbus into separate binary packages, what
On 13/10/14 14:38, Dale R. Worley wrote:
My general understanding is that the traditional behavior when you
need an editor but the user hasn't specified one is to use vi, and
so people who don't want vi *always* set $VISUAL in their
environment.
The Right Thing™ is distro-specific. Debian and
On 21/10/14 13:03, Christian Seiler wrote:
That is definitely a good point. Also note that /lib32 is not included
in the patch...
lib64 is part of the Linux/x86_64 platform ABI (the exact path
/lib64/ld-linux-x86-64.so.2 is hard-coded into every Linux/x86_64
executable) so it cannot be
On 21/10/14 19:18, Lennart Poettering wrote:
Well, on some distros lib64 is a symlink on others it isn't. Doesn't
Debian have /lib/arch or so with /lib64 just a symlink to the right
subdir?
My Debian laptop has /lib64 as a real directory, containing a
ld-linux-x86-64.so.2 symlink into
On 21/10/14 20:30, Lennart Poettering wrote:
But in cases like the iptables tool (which
is written in a style that kinda requires the usage of shell scripts
to invoke it, since it is more a programming language and is seldom
called just once at boot)
If your ruleset is static (e.g. does not
On 21/10/14 20:25, Lennart Poettering wrote:
Ah, well, at least they should make the lib64 thing arch dependent.
Multiarch means that whichever architecture systemd happens to have been
compiled for, /lib64 might exist. If it does, it's a system library
directory.
(Consider an i386 or armhf
On 22/10/14 12:37, Lennart Poettering wrote:
When used with kdbus we actually do check for that client-side
capability. THis is not available on dbus1 however, since we cannot
determine the capability racefreely and thus safely
... because the kernel doesn't give us that ability on Unix
On 23/10/14 12:21, Lennart Poettering wrote:
The behaviour should really be to:
1. take the paths from configure switches
2. if they are not specified, try to get them from pkg-config
3. if the relevant pkg-config files are not installed, generate an error and
refuse build
Actually...
On 20/10/14 08:19, Chaiken, Alison wrote:
../systemd/src/shared/util.h:51:4: error: #error Unknown pid_t size
# error Unknown pid_t size
^
In file included from ../systemd/src/shared/util.h:87:0,
from ../systemd/src/shared/log.c:33:
On 28/10/14 10:06, Mihamina Rakotomandimby wrote:
what to do if
there is the need to package a daemon and there is only a SysV init
script available
LSB init scripts should continue to work fine. Make sure they have LSB
pseudo-headers (Required-Start etc.) for their dependencies.
if running
On 28/10/14 16:34, Colin Guthrie wrote:
It seems we have different permissions for /etc/{g}shadow than fedora.
We don't package it as ,root,root but rather 0440,root,shadow.
Who is we? Mageia? FYI, Debian uses 0640 root:shadow for the same files.
We can then run some tools that need
On 06/11/14 14:16, Zbigniew Jędrzejewski-Szmek wrote:
What matters is how it is all arranged:
- if there's a job that does stuff, and then calls reboot or shutdown
- a hook into the shutdown or reboot target does some work
unattended-upgrades is currently the latter: the user shuts down (or
On 09/11/14 02:08, Casey Schaufler wrote:
Thus, dbus is a fine example where SMACK64EXEC is a bad idea. Because you
want a system bus and a user bus with different attributes you want it to get
the Smack label at launch time, just like you do for UID and capability sets.
I think there's a much
On 14/11/14 16:46, Stef Walter wrote:
On 14.11.2014 16:39, Lennart Poettering wrote:
The services like hostnamed explicitly provide stable object
paths and suchlike so that clients can completely ignore when
the services go away and come back...
Most DBus services are not like that, and
On 25/11/14 23:46, David Herrmann wrote:
In particular, if gdbus runs AddMatch(), it assumes the match takes
effect immediately. If it sends a method call to another service after
installing the match, and this triggers a signal, gdbus assumes the
AddMatch() call to have succeeded (without
On 04/12/14 08:56, arnaud gaboury wrote:
-$DBUS_SESSION_BUS_ADDRESS
For reasons I ignore (far from being a dbus expert), the
$DBUS_SESSION_BUS_ADDRESS as returned by the
$systemctl --user show-environment did not work for mate-settings-daemon.
...
$systemctl --user show-environment returns
On 18/12/14 08:05, Andrei Borzenkov wrote:
Any initscript that is using su - would [cause badness]
Don't do that then? Init scripts are fairly clearly not login sessions.
Which init scripts do that?
In Debian, our init scripts would typically use start-stop-daemon
--chuid whateveruser --start
On 18/12/14 14:10, Dale R. Worley wrote:
Simon McVittie simon.mcvit...@collabora.co.uk writes:
On 18/12/14 08:05, Andrei Borzenkov wrote:
Any initscript that is using su - would [cause badness]
Don't do that then? Init scripts are fairly clearly not login sessions.
Which init scripts do
On 22/12/14 14:33, Lennart Poettering wrote:
I thought Debian would nowadays mount /usr from the initrd too?
We now do that in unstable, but unfortunately this change wasn't well
coordinated and caused several serious regressions, so it's unlikely to
migrate into Debian 8. (A separate /usr on
On 24/01/15 10:09, Topi Miettinen wrote:
For example, smartd only needs access to /dev/sd*.
Let me spell that differently: smartd only needs the ability to make
arbitrary filesystem changes, defeating any possible configurable
security mechanism.
If you give it access to /dev/sd* but not to
On 23/01/15 17:52, Lennart Poettering wrote:
On Fri, 23.01.15 12:27, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
El 23/01/15 a las 10:31, Lennart Poettering escribió:
The rc-local generator only exists to add compat support for those
systems where it never was a sysvinit script
part is getting environment variables pushed around, for
which I don't have a complete patch yet (but I'm going to work on that
within the next couple of weeks).
S
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel
On 02/02/15 10:22, Dimitri John Ledkov wrote:
I would like to experiment with a user-bus, potentially in a transient
manner to have 3 buses: system, user, session busses.
I still think it's a bad idea to have both a user bus and a session bus.
Having things on the wrong bus is definitely an API
-Bus-activated, non-systemd services will get the variables), and there
are a bunch of other variables set in /etc/X11/Xsession.d or equivalent
that should also be uploaded if present.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com
On 03/02/15 10:16, Stef Bon wrote:
I've never understood why the session bus is started through dbus-launch.
If we move from a per-login-session to a per-user-session bus, then it
won't be; dbus-launch will become solely for the people who run twm
under xdm or something, but who still want to
. If a sysadmin
wants this badly enough, they can put a hook in their initramfs to mount
/usr/local.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http
enhancement
for dbus, which I'm currently upstreaming into dbus 1.9.x.
Regards,
S
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
On 15/01/15 09:28, Colin Guthrie wrote:
Although if the script is in bash I'd use if [ -d ... rather than if
test -d ... as (and bash experts (Harald?) can correct me here if I'm
wrong) I believe [ is a bash built in (even if it is a binary in
/usr/bin/), whereas it would have to fork out to
On 20/01/15 20:33, Martin Pitt wrote:
Dimitri John Ledkov [2015-01-20 18:23 +]:
With parallel test harness in automake (everyone should have it by
now)
Yay, thanks for pointing this out! That makes the whole thing indeed
much friendlier.
systemd currently has
AM_INIT_AUTOMAKE([foreign
, SELinux, etc.) and confine your users,
you might be able to achieve what you think you have already achieved.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http
On 19/02/15 21:26, Djalal Harouni wrote:
On Thu, Feb 19, 2015 at 05:44:34PM +0100, Djalal Harouni wrote:
On Thu, Feb 19, 2015 at 01:05:22PM +, Simon McVittie wrote:
On 19/02/15 12:43, Lukasz Skalski wrote:
r = get_creds_by_message(a, m, SD_BUS_CREDS_PID|SD_BUS_CREDS_EUID, creds,
error
{}, not { LinuxSecurityLabel: [] } or
{ LinuxSecurityLabel: [ '\0' ] }.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On 30/01/15 22:53, Elias Probst wrote:
IMHO, env variables are something we should get rid of in the long term.
It might be fine for now to provide some legacy-compatibility mechanisms
(like your not-yet-written tool), but to me environment variables are
something straight out of the dark
On 30/01/15 09:30, Simon McVittie wrote:
user-session
I don't think there is a standard term for this so I'm making one up.
Notes from the hackfest: A few people called these super-sessions when
we discussed them. I preferred user-session tbh, but if people want to
standardize
. The differences are because, historically, this sort of plumbing
was something that every distribution had to invent for itself.
S
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel mailing list
systemd-devel
1 - 100 of 232 matches
Mail list logo
