in with mtools (or equivalent) when required.
--
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
://lists.debian.org/debian-devel/2015/08/msg00354.html
--
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
changes, but
then setting DBUS_SESSION_BUS_ADDRESS appropriately is your responsibility.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
?
(I realise that one possible reason for a user-space service is so that
it can aggregate all the periodic polling, on filesystems that don't
have anything better you can do - that's why FAM had a daemon, if I
remember correctly.)
--
Simon McVittie
Collabora Ltd. http://www.collabora.com
://bugs.freedesktop.org/show_bug.cgi?id=46787
--
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
in this way. One of dbus-daemon's roles is to impose a
total ordering on messages - it's the component that makes the arbitrary
decision on how the individual message streams get interleaved.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com
similarly?)
--
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
for systemd.freedesktop.org's web content.
This makes /srv pretty useless from a distribution point of view, but
useful for sysadmins - Debian's take on that directory is essentially
don't put anything in /srv out-of-the-box, so that the sysadmin can use
it however they want to (a lot like /opt).
--
Simon
, then the session bus *is*
the user bus.
S
--
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
coreutils,
and perhaps I'd think differently if I did.
--
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
this means you get a `dbus-daemon --session` per user if you
have dbus = 1.9.14 compiled with the --enable-user-session option, and
systemd, inside the container.
Similarly, kdbus systems (inside or outside a container) always get a
user bus per user, as far as I understand it.
--
Simon McVittie
On 07/05/15 10:30, Martin Vogt wrote:
I try to give any user rw permissions on /dev/nvidia*.
Usually this is done by adding the user to group video, but
here the group is configured on NIS and I cannot change it.
On a modern Linux system you should instead be able to tag those devices
as
modules
were, I'd be asking you why (and whether) you are sending enough patches
that it makes any practical difference, and if you are, whether pushing
them to a git repository might make more sense :-)
--
Simon McVittie
Collabora Ltd. http://www.collabora.com
://permalink.gmane.org/gmane.comp.freedesktop.dbus/13663.
--
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
string (derived from /proc/$pid).
The log info is mentioned in the syslog message when something is
denied, but is not used for authentication, and is not made available to
dbus-daemon's clients such as polkit.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com
its
installation paths, rather than for it to do what I mean and alter its
defaults depending whether it thinks it's on a Debian or Red Hat derivative.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel mailing list
systemd
or dbus.
--
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
dbus.service if that's (part or all of) the
solution, but before I can do that we need to come up with a solution
that doesn't cause new dependency cycles.
S
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel mailing list
systemd
On 24/03/15 14:40, Stef Walter wrote:
On 24.03.2015 15:22, Tom Gundersen wrote:
It all comes down to what you intend the fields to mean. Now we mean
the field to mean the real localtime of the server (as seen from the
client), whereas you want it to mean the localtime the server thinks
it
On 10/03/15 16:01, Lennart Poettering wrote:
Yes, dbus is currently not compatible with stateless bootups. PAM is
neither. For PAM we ship a tmpfiles snippet to work around this, for
dbus we don't though, since kdbus kinda makes the problem go away...
In the meantime, you might be interested
.
# now data.tar.gz contains e.g. ./usr/bin/foo, ./usr/include/foo.h,
# ./usr/lib/i386-linux-gnu/libfoo.so*
and most other packaging systems are similar.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel mailing list
systemd
with the .pc filename.
If dconf never breaks API, no problem; if it does, it will hopefully
start including an API version in the .pc filename at that point.
--
Simon McVittie
Collabora Ltd. http://www.collabora.com/
___
systemd-devel mailing list
systemd-devel
will override the earlier setting.
--
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
was keen to make D-Bus
support user sessions without requiring kdbus - if we can get this sort
of thing fixed now, in parallel with the kdbus developers getting it
through kernel review, then that's one less regression to fix when kdbus
eventually lands.)
Thanks,
smcv
--
Simon McVittie
On 09/03/15 12:32, Simon McVittie wrote:
I'm developing a patch for udisks to fix its interaction with systemd
user-sessions (, and I would like to check that the behaviour I propose
is consistent with udisks' and systemd's security models.
Forgot to mention that this is
https
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
, 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
. 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
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
. 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
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
-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
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
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
[For those who are there, I'll be at the system hackfest today and at
FOSDEM this weekend, so if you are interested in these topics, please
talk to me about them; I'll try to summarize discussion to these lists.
For those not there, I'll try to keep up with responses via email and
raise any
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
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
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
Adding D-Bus mailing list to Cc; questions about the user bus are
significant for D-Bus as well as for systemd --user, and modifications
of dbus-launch doubly so.
On 08/01/15 11:55, Colin Guthrie wrote:
I've got a modified dbus-launch that can be slotted in nicely
I'm happy for dbus to get
On 08/01/15 16:03, Dimitri John Ledkov wrote:
There is upstart --user spawned per session, and everything is under
it. The sessions' logind cgroups are parent of all processes within a
session, and there are sub cgroups as needed for contained
jobs/processes. Thus for three graphical sessions,
On 08/01/15 17:24, Simon McVittie wrote:
This is a conversation about the distinction between a per-(uid,machine)
bus (the user bus) and a per-login-session bus (the session bus).
We've had this discussion several times in the past
Some further reading; I knew this conversation was old, I
On 08/01/15 14:36, Colin Guthrie wrote:
Lennart Poettering wrote on 08/01/15 13:19:
Yes, the idea is that these services become singleton services of the
user, and the sessions ultimately only retain a stub process
But dbus-daemon itself might be excluded from that no? I mean the model
is
On 08/01/15 17:04, Colin Guthrie wrote:
Although when I discussed this on the ML
before, one case which a PAM solution wouldn't address is people running
startx after logging into a tty session
I personally am very tempted to say that startx users get to keep both
pieces, and that the *dm
On 08/01/15 17:42, Dimitri John Ledkov wrote:
On 8 January 2015 at 17:24, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
I personally think having only the user bus (and having
(G_|DBUS_)BUS_TYPE_SESSION connect to it) is the best long-term setup,
because it's easy to understand
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
(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 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
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 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 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 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 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 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 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 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/
._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 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
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 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 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 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 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 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 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 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,
101 - 200 of 232 matches
Mail list logo
