Re: [systemd-devel] [ANNOUNCE] systemd v39
On Wednesday 2012-01-25 02:02, Lennart Poettering wrote: People have been asking us to maintain a NEWS file for systemd. We have now added that: http://cgit.freedesktop.org/systemd/systemd/plain/NEWS I have included all news from the previous release v38 there, please have a look. [v39] * If a group adm exists, journal files are automatically owned by them This sounds like it has the potential that journal files suddenly beomce writable by a random user group that has existed previously. [v38] * Output of SysV services is now forwarded to both the console and the journal by default, not only just the console. I would actually prefer if it wrote that to the current tty that invoked the start action, rather than the console which is stowed away in a deep cellar... * Processes with '@' in argv[0][0] are now excluded from the final shut-down killing spree Did you consider http://lists.freedesktop.org/archives/systemd-devel/2012-January/004221.html ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v39
On Wed, Jan 25, 2012 at 11:11, Jan Engelhardt jeng...@medozas.de wrote: On Wednesday 2012-01-25 02:02, Lennart Poettering wrote: [v39] * If a group adm exists, journal files are automatically owned by them This sounds like it has the potential that journal files suddenly beomce writable by a random user group that has existed previously. The group 'adm' isn't random, is it? It's pretty commonly used for 'system monitoring' users. * Processes with '@' in argv[0][0] are now excluded from the final shut-down killing spree Did you consider http://lists.freedesktop.org/archives/systemd-devel/2012-January/004221.html ? How? We do not and can not use pivot_root() during bootup. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v39
Am 25. Januar 2012 12:00 schrieb Kay Sievers kay.siev...@vrfy.org: On Wed, Jan 25, 2012 at 11:11, Jan Engelhardt jeng...@medozas.de wrote: On Wednesday 2012-01-25 02:02, Lennart Poettering wrote: [v39] * If a group adm exists, journal files are automatically owned by them This sounds like it has the potential that journal files suddenly beomce writable by a random user group that has existed previously. The group 'adm' isn't random, is it? It's pretty commonly used for 'system monitoring' users. In Debian (and derivatives) group adm is shipped by the base-passwd package, so guaranteed to exist. The relevant documentation reads: adm Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group. The log files in /var/log that are created by the syslog daemon, are owned by group adm. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v39
On Wed, Jan 25, 2012 at 12:59, Michael Biebl mbi...@gmail.com wrote: Am 25. Januar 2012 12:00 schrieb Kay Sievers kay.siev...@vrfy.org: On Wed, Jan 25, 2012 at 11:11, Jan Engelhardt jeng...@medozas.de wrote: On Wednesday 2012-01-25 02:02, Lennart Poettering wrote: [v39] * If a group adm exists, journal files are automatically owned by them This sounds like it has the potential that journal files suddenly beomce writable by a random user group that has existed previously. The group 'adm' isn't random, is it? It's pretty commonly used for 'system monitoring' users. In Debian (and derivatives) group adm is shipped by the base-passwd package, so guaranteed to exist. The relevant documentation reads: adm Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group. The log files in /var/log that are created by the syslog daemon, are owned by group adm. That sounds all pretty sane to me, and like something distros should adopt, if they haven't already. We've did this kind harmonisation with the udev system groups a few years back already, and I think just adopting 'adm' makes the most sense here. Distros who don't want that can patch the sources as needed. We should always provide some common default, one that makes the intention clear to have some sort of Linux distro default. And any sensible common pattern that is already in use, we should just adopt. I don't think caring too much about cases where someone might have put all the people he did not trust in the group 'adm', is really needed here. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] automount regression
On Wed, Jan 25, 2012 at 12:39 PM, Tom Gundersen t...@jklm.no wrote:
I noticed a regression in the automount handling that I could not
immediately figure out. I know for a fact that this used to work a
long time ago, and that it does not work with v39, but I have not
bisected further.
It seems this was caused by:
commit 9ddc4a26e56b06cd7774a03597980351855d8d54
Author: Michal Schmidt mschm...@redhat.com
Date: Fri Jan 13 23:55:28 2012 +0100
mount: fix quota
quotacheck.service and quotaon.service were not pulled in for fstab mounts.
Fix it by not clearing the default_dependencies flag.
The root filesystem may have quotas too, so don't check for / there.
No need to have duplicate code for adding dependencies on umount.target.
https://bugzilla.redhat.com/show_bug.cgi?id=773431
The following (partial) revert fixed my problem, but I'm not sure what
the proper fix would be.
commit 38ed3b9dcf083a614fc32e53a59d8b936aae6ee5
Author: Tom Gundersen t...@jklm.no
Date: Wed Jan 25 15:33:18 2012 +0100
mount: allow a mount unit to be WantedBy, but not Before local-fs.target
This partially reverts 9ddc4a26e56b06cd7774a03597980351855d8d54, probably
breaking lots of other things in the process.
diff --git a/src/mount.c b/src/mount.c
index 6d0af4e..5e2c8b6 100644
--- a/src/mount.c
+++ b/src/mount.c
@@ -584,6 +584,9 @@ static int mount_load(Unit *u) {
if (UNIT(m)-fragment_path)
m-from_fragment = true;
+else if (m-from_etc_fstab)
+m-meta.default_dependencies = false;
+
if (!m-where)
if (!(m-where = unit_name_to_path(u-id)))
return -ENOMEM;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v39
On Wed, 25.01.12 11:11, Jan Engelhardt (jeng...@medozas.de) wrote: [v39] * If a group adm exists, journal files are automatically owned by them This sounds like it has the potential that journal files suddenly beomce writable by a random user group that has existed previously. They are only readable to adm, not writable. And adm has been defined as the group which (among other things possibly) is allowed to read log files on Debian and a number of other Linux distributions. I think this is quite safe to do, and are very useful semantics that make sense to adopt across all Linux distributions. If a distro believes this a huge security thread, they are welcome to maintain a patch to our sources in their rpms to use a different group. [v38] * Output of SysV services is now forwarded to both the console and the journal by default, not only just the console. I would actually prefer if it wrote that to the current tty that invoked the start action, rather than the console which is stowed away in a deep cellar... We explicitly want to avoid that services are entirely isolated from the user session they are started from. Running a service with the tty of the user running the command would be the absolute opposite of isolated. In fact, this kind of isolation is one of the big features of systemd. * Processes with '@' in argv[0][0] are now excluded from the final shut-down killing spree Did you consider http://lists.freedesktop.org/archives/systemd-devel/2012-January/004221.html ? Hmm? what pecisely? I though I already made clear that there's a difference between asking did this process originate from the initrd? and shall this process be killed during the final killing spree?. While there's a big voerlap, and only processes which qualify for the former shall answer yes to the latter they aren't the same thing. Or, in other words: I really want people to think about this whole problem before they exclude themselves from the killing spree. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] logind: add sys_tty_config capability, to let it use VT_ACTIVATE ioctl on activate action
Good day,
Problem is that systemd-loginctl activate session-id gives
something like D-Bus call failed: Operation not permitted, while
strace of logind process looks like this:
epoll_wait(4, {{EPOLLIN, {u32=3, u64=3}}}, 1, -1) = 1
epoll_wait(9, {{EPOLLIN, {u32=166352544, u64=166352544}}}, 1, 0) = 1
recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{l\1\0\1\6\0\0\0\2...
recvmsg(8, 0xbfc3636c, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily
unavailable)
open(/dev/tty0, O_RDWR|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 13
ioctl(13, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(13, VT_ACTIVATE, 0x1) = -1 EPERM (Operation not permitted)
close(13) = 0
sendmsg(8, {msg_name(0)=NULL, msg_iov(2)=[{l\3\1\1\34\0\0\0\243\0...
So it looks like activate fails without that capability.
I'm not sure what it's supposed to do though, and stumbled upon it
while looking into unrelated issue, so maybe it's supposed to act this
way.
michich seemed to agree on irc that the cap should be there, but since
it doesn't seem to be in git yet, I thought I'd mail the patch.
From 1e9da2f9ba2e996987eb6e7b8810efe2b933d2de Mon Sep 17 00:00:00 2001
From: Mike Kazantsev mk.frag...@gmail.com
Date: Wed, 25 Jan 2012 21:09:03 +0600
Subject: [PATCH] logind: add sys_tty_config capability, to let it use
VT_ACTIVATE ioctl on activate action
---
units/systemd-logind.service.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/units/systemd-logind.service.in b/units/systemd-logind.service.in
index c332039..531b8f7 100644
--- a/units/systemd-logind.service.in
+++ b/units/systemd-logind.service.in
@@ -14,7 +14,7 @@ Description=Login Service
ExecStart=@rootlibexecdir@/systemd-logind
Type=dbus
BusName=org.freedesktop.login1
-CapabilityBoundingSet=CAP_AUDIT_CONTROL CAP_CHOWN CAP_KILL CAP_DAC_READ_SEARCH
CAP_DAC_OVERRIDE CAP_FOWNER
+CapabilityBoundingSet=CAP_AUDIT_CONTROL CAP_CHOWN CAP_KILL CAP_DAC_READ_SEARCH
CAP_DAC_OVERRIDE CAP_FOWNER CAP_SYS_TTY_CONFIG
# Increase the default a bit in order to allow many simultaneous
# logins since we keep one fd open per session.
--
1.7.8.1
--
Mike Kazantsev // fraggod.net
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: add creation of /var/lib/systemd path, used by logind
Good day, Another issue I've spotted with logind on my system. systemd-loginctl enable-linger goes to src/login/logind-dbus.c:1191, which seem to do: r = safe_mkdir(/var/lib/systemd/linger, 0755, 0, 0); ...and fails, producing something like D-Bus call failed: No such file or directory from systemd-loginctl, because /var/lib/systemd doesn't seem to be installed during regular make install. Not sure if it has to be abstracted via localstatedir or something, but since it's hard-coded in logind anyway, I thought not to bother with it. From ff10029e24cfc4d05228c1ac7b3dc06e615c8e0c Mon Sep 17 00:00:00 2001 From: Mike Kazantsev mk.frag...@gmail.com Date: Wed, 25 Jan 2012 21:24:02 +0600 Subject: [PATCH] build-sys: add creation of /var/lib/systemd path, used by logind --- Makefile.am |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index 15190b4..08296b2 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1979,6 +1979,8 @@ polkitpolicy_in_files += \ logind-install-data-hook: $(MKDIR_P) -m 0755 \ + $(DESTDIR)$(rootprefix)/var/lib/systemd + $(MKDIR_P) -m 0755 \ $(DESTDIR)$(systemunitdir)/multi-user.target.wants ( cd $(DESTDIR)$(systemunitdir) \ rm -f dbus-org.freedesktop.login1.service \ -- 1.7.8.1 -- Mike Kazantsev // fraggod.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v39
On 01/25/2012 03:57 PM, Lennart Poettering wrote: On Wed, 25.01.12 11:11, Jan Engelhardt (jeng...@medozas.de) wrote: I would actually prefer if it wrote that to the current tty that invoked the start action, rather than the console which is stowed away in a deep cellar... We explicitly want to avoid that services are entirely isolated from the user session they are started from. Running a service with the tty of the user running the command would be the absolute opposite of isolated. We could make systemctl start ... dump a few of the service's lines from the journal before exiting. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: add creation of /var/lib/systemd path, used by logind
On Wed, Jan 25, 2012 at 16:33, Mike Kazantsev mk.frag...@gmail.com wrote: Good day, Another issue I've spotted with logind on my system. systemd-loginctl enable-linger goes to src/login/logind-dbus.c:1191, which seem to do: r = safe_mkdir(/var/lib/systemd/linger, 0755, 0, 0); ...and fails, producing something like D-Bus call failed: No such file or directory from systemd-loginctl, because /var/lib/systemd doesn't seem to be installed during regular make install. Not sure if it has to be abstracted via localstatedir or something, but since it's hard-coded in logind anyway, I thought not to bother with it. logind-install-data-hook: $(MKDIR_P) -m 0755 \ + $(DESTDIR)$(rootprefix)/var/lib/systemd + $(MKDIR_P) -m 0755 \ It probably is: $(localstatedir)/lib. Rootprefix must not be involved. That stuff is never in /usr. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: add creation of /var/lib/systemd path, used by logind
On Wed, 25 Jan 2012 16:43:35 +0100 Kay Sievers kay.siev...@vrfy.org wrote: On Wed, Jan 25, 2012 at 16:33, Mike Kazantsev mk.frag...@gmail.com wrote: ... Not sure if it has to be abstracted via localstatedir or something, but since it's hard-coded in logind anyway, I thought not to bother with it. logind-install-data-hook: $(MKDIR_P) -m 0755 \ + $(DESTDIR)$(rootprefix)/var/lib/systemd + $(MKDIR_P) -m 0755 \ It probably is: $(localstatedir)/lib. Rootprefix must not be involved. That stuff is never in /usr. Fair enough. Updated version follows. From c48f23ae82a8efac59f025e2534a97754b279f60 Mon Sep 17 00:00:00 2001 From: Mike Kazantsev mk.frag...@gmail.com Date: Wed, 25 Jan 2012 21:24:02 +0600 Subject: [PATCH] build-sys: add creation of /var/lib/systemd path, used by logind --- Makefile.am |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index 15190b4..9f2a893 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1979,6 +1979,8 @@ polkitpolicy_in_files += \ logind-install-data-hook: $(MKDIR_P) -m 0755 \ + $(DESTDIR)$(localstatedir)/lib/systemd + $(MKDIR_P) -m 0755 \ $(DESTDIR)$(systemunitdir)/multi-user.target.wants ( cd $(DESTDIR)$(systemunitdir) \ rm -f dbus-org.freedesktop.login1.service \ -- 1.7.8.1 -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] hwclock
Hi David, On Wed, Jan 25, 2012 at 3:49 PM, David Thurgood d.r.thurg...@gmx.com wrote: I am hoping that this is an appropriate place for a feature request with respect to the program hwclock. hwclock is part of the util-linux package, so you'd probably have more luck emailing util-li...@vger.kernel.org. systemd does not write to your rtc (though it does read it). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v39
Michal Schmidt (mschm...@redhat.com) said: On 01/25/2012 03:57 PM, Lennart Poettering wrote: On Wed, 25.01.12 11:11, Jan Engelhardt (jeng...@medozas.de) wrote: I would actually prefer if it wrote that to the current tty that invoked the start action, rather than the console which is stowed away in a deep cellar... We explicitly want to avoid that services are entirely isolated from the user session they are started from. Running a service with the tty of the user running the command would be the absolute opposite of isolated. We could make systemctl start ... dump a few of the service's lines from the journal before exiting. At that point you're then trying to define heuristics about what the proper value for 'a few' is, and then you're guaranteed to get it wrong for some set of services. Not sure it's worth the effort. Bill ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] hwclock
On Wed, 25.01.12 14:49, David Thurgood (d.r.thurg...@gmx.com) wrote: Dear Sir, I am hoping that this is an appropriate place for a feature request with respect to the program hwclock. This relates to a very old problem, which as I remember goes back to the PC's of the 70's and 80's. My present PC seems to have just the same issue. It is this, that when the hardware clock is adjusted/reset then the BIOS wake-on-alarm is deactivated. I am sure that you guys know this well enough. So this is the simple request, please read the alarm state before any adjustments, and restore them afterwards. Thus whatever the user has set will remain valid. I think this is something that should be worked around in the kernel drivers. Please file a bug on https://bugzilla.kernel.org/ ! Feel free to CC me on that bug, my login there is mzxre...@0pointer.de Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v39
On 01/25/2012 05:34 PM, Bill Nottingham wrote: Michal Schmidt (mschm...@redhat.com) said: We could make systemctl start ... dump a few of the service's lines from the journal before exiting. At that point you're then trying to define heuristics about what the proper value for 'a few' is, and then you're guaranteed to get it wrong for some set of services. Not sure it's worth the effort. 'A few' could be defined as everything the service wrote between the time we told it to start and the time it finished starting (or failed). systemd has the timestamps. Or these important events can be found in the journal as well. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] BindTo not working as expected with .target ?
Hi all, I'm trying to get a .target working as a trigger one action then go back to not activated state and despite Lennart help on IRC, it keeps failing, so it might indicate a bug : foobar.target : [Unit] Description=my trigger target BindTo=myaction.service myaction.service: [Unit] Description=my action [Service] ExecStart=/bin/true Type=oneshot RemainAfterExit=false when starting foobar.target, myaction.service is correctly started, then service terminates, is no longer active, but foobar.target is still seen as active. BTW, it could be interesting to allow foobar.target.bindto symlink to be created, so we wouldn't have to modify system targets (for instance, sigpwr.target ;) to add BindTo dependencies. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADS-UP] Interface Portability And Stability Chart
Heya, to be nice to those who are interested in maintaining a level of compatibility with the interfaces we have introduced with systemd without making use of systemd, I have put together this extensive (and hopefully comprehensive) table: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart Many of these APIs are already in heavy usage by applications and 3rd party code. Of course, it's up to you to decide whether your time is best spent on reimplementing these systemd interfaces instead of just adopting systemd right-away... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Interface Portability And Stability Chart
On Wed, Jan 25, 2012 at 12:01 PM, Lennart Poettering lenn...@poettering.net wrote: Many of these APIs are already in heavy usage by applications and 3rd party code. The Arch Linux native initscripts just recently adopted your /etc/locale.conf file, and could go in the Known Other Implementations column for that. https://wiki.archlinux.org/index.php/Locale.conf -William Swanson ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Interface Portability And Stability Chart
On Wed, 25.01.12 13:04, William Swanson (swanson...@gmail.com) wrote: On Wed, Jan 25, 2012 at 12:01 PM, Lennart Poettering lenn...@poettering.net wrote: Many of these APIs are already in heavy usage by applications and 3rd party code. The Arch Linux native initscripts just recently adopted your /etc/locale.conf file, and could go in the Known Other Implementations column for that. https://wiki.archlinux.org/index.php/Locale.conf Thanks! Added! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Interface Portability And Stability Chart
On Wed, Jan 25, 2012 at 10:46 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 25.01.12 13:04, William Swanson (swanson...@gmail.com) wrote: On Wed, Jan 25, 2012 at 12:01 PM, Lennart Poettering lenn...@poettering.net wrote: Many of these APIs are already in heavy usage by applications and 3rd party code. The Arch Linux native initscripts just recently adopted your /etc/locale.conf file, and could go in the Known Other Implementations column for that. https://wiki.archlinux.org/index.php/Locale.conf Thanks! Added! For what it's worth, Arch's also has support for: /etc/tmpfiles.d /etc/hostname /etc/sysctl.d /etc/vconsole.conf /run In addition to the initrd interfaces for fsck and shutdown (but they are not in the table). (I tried to add this myself to the chart, but it appears it is immutable.) Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Interface Portability And Stability Chart
On Wed, 25.01.12 23:12, Tom Gundersen (t...@jklm.no) wrote: The Arch Linux native initscripts just recently adopted your /etc/locale.conf file, and could go in the Known Other Implementations column for that. https://wiki.archlinux.org/index.php/Locale.conf Thanks! Added! For what it's worth, Arch's also has support for: /etc/tmpfiles.d /etc/hostname /etc/sysctl.d /etc/vconsole.conf /run Thanks, added! In addition to the initrd interfaces for fsck and shutdown (but they are not in the table). Well, they are included in the initrd interface item, the flag files bit of it. I have no added ArchLinux for both sides as consumer and provider of this interface, right? (I tried to add this myself to the chart, but it appears it is immutable.) Oh, it's immutable if you didn't log in into the wiki. I figure that's a bit weirdly named in moinmoint. But basically, if you have a wiki account you get full write access, and you are welcome to make those changes. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Interface Portability And Stability Chart
On Wed, Jan 25, 2012 at 11:40 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 25.01.12 23:12, Tom Gundersen (t...@jklm.no) wrote: In addition to the initrd interfaces for fsck and shutdown (but they are not in the table). Well, they are included in the initrd interface item, the flag files bit of it. I have no added ArchLinux for both sides as consumer and provider of this interface, right? Correct. Oh, it's immutable if you didn't log in into the wiki. I figure that's a bit weirdly named in moinmoint. But basically, if you have a wiki account you get full write access, and you are welcome to make those changes. Ah, I see. I'll keep it up to date then, if things change. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
