Re: [systemd-devel] udev firmware loading
On Wed, 2013-11-27 at 13:11 +0100, Kay Sievers wrote: It would need a MESSSAGE_ID= and a few key/value pairs with the file name, the driver name and such to send out. The journal could get a service activation feature by message id ... Where does that stand, btw ? Hasn't activate-by-message-id been on the roadmap for a while ? That would let us do some neat things and make the journal much more useful. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Update systemd-inhibit --help output
This occurrence of handle-sleep-key was overlooked when it was split. See the attached patch. 0001-Update-systemd-inhibit-help-output.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Handling lid close in logind?
On Tue, 2012-09-18 at 00:28 +0200, Lennart Poettering wrote: On Mon, 03.09.12 22:10, Matthias Clasen (matthias.cla...@gmail.com) wrote: On Mon, Sep 3, 2012 at 5:17 AM, Richard Hughes hughsi...@gmail.com wrote: I don't think the desktop guys want any kind of authentication when the lid is closed. How feasible would it be to do the suspend when the inhibit is removed? I guess then it puts logind into a active but will suspend asap state which might be difficult to handle. As I said on irc, the user experience I envision in this case is: - user closes lid - polkit dialog is shown (not useful because the lid is closed) - we beep a few times to cause the user to open the lid and see the dialog - if the lid is not opened, we forcefully suspend after a few seconds A similar situation where we can't wait for a policykit dialog to be answered is emergency shutdown when the battery runs empty. So, what I wonder is: if this inhibitor is supposed to be ignored, why take it in the first place? I mean, the inhibitor is supposed to inhibit, no? To me it appears really as if the inhibitor should not have been taken in the first place/not have been allowed to be taken in the first place, rather then not being honoured after it was successfully taken. The think thats missing here is that 'click Suspend in menu' and 'close the lid' are really quite different, in terms of how we need to handle them. The first is a user action that can be handled with inhibitors just fine - we'll show the dialog, the user makes an informed decision, no harm. The second is a hardware event (admittedly triggered by user action), we really have no choice but to react to it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-inhibit --list doesn't work
See attached patch 0001-Make-systemd-inhibit-list-work.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Handling lid close in logind?
On Mon, Sep 3, 2012 at 5:17 AM, Richard Hughes hughsi...@gmail.com wrote: I don't think the desktop guys want any kind of authentication when the lid is closed. How feasible would it be to do the suspend when the inhibit is removed? I guess then it puts logind into a active but will suspend asap state which might be difficult to handle. As I said on irc, the user experience I envision in this case is: - user closes lid - polkit dialog is shown (not useful because the lid is closed) - we beep a few times to cause the user to open the lid and see the dialog - if the lid is not opened, we forcefully suspend after a few seconds A similar situation where we can't wait for a policykit dialog to be answered is emergency shutdown when the battery runs empty. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] CanSuspend always says 'na'
It shouldn't, since my system suspends just fine. The attached patch should fix that. 0001-logind-interpret-the-can_sleep-return-value-properly.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] fix a man page reference
trivial patch to fix a leftover from the latest round of renamings. 0001-journald-refer-to-the-correct-man-page.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] selinux policy updates for logind
Matthias What AVCs are you seeing? I'm getting 'access denied' when trying to call e.g. org.freedesktop.login1.Manager.Reboot from a user process. Which seems disingenuous, considering that logind has PolicyKit support to control access to these methods. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] selinux policy updates for logind
On Wed, Dec 28, 2011 at 9:25 AM, Daniel J Walsh dwa...@redhat.com wrote: Well are you seeing a AVC about local_login_t sending a dbus message to systemd? I don't know, I haven't checked. But the patch fixes the problem, and is pretty obvious... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] selinux policy updates for logind
I've spent some time playing with the ConsoleKit-replacement functionality in logind, and noticed that I couldn't test the PolicyKit integration for the poweroff/reboot methods in logind, since selinux doesn't let my method calls reach their destination. Matthias diff -up systemd-37/src/org.freedesktop.login1.conf.selinux systemd-37/src/org.freedesktop.login1.conf --- systemd-37/src/org.freedesktop.login1.conf.selinux▸‧2011-12-23 21:09:32.795513513 -0500 +++ systemd-37/src/org.freedesktop.login1.conf▸‧2011-12-23 21:10:36.456511229 -0500 @@ -69,6 +69,14 @@ send_member=ActivateSession/ allow send_destination=org.freedesktop.login1 + send_interface=org.freedesktop.login1.Manager + send_member=PowerOff/ + +allow send_destination=org.freedesktop.login1 + send_interface=org.freedesktop.login1.Manager + send_member=Reboot/ + +allow send_destination=org.freedesktop.login1 send_interface=org.freedesktop.login1.Seat send_member=ActivateSession/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: allow building without libnotify
On Wed, Nov 24, 2010 at 5:57 AM, Kay Sievers kay.siev...@vrfy.org wrote: On Wed, Nov 24, 2010 at 08:36, Thierry Reding thierry.red...@avionic-design.de wrote: This patch makes the libnotify dependency optional and doesn't build the systemd-gnome-ask-password-agent utility if libnotify is not available. Since libnotify = 0.7.0 requires gtk+-3.0, this patch may be useful for environments where upgrading Gtk is not an option. Yeah, would be good to solve that. Maybe that's the simplest way to do it. One other option would be to use some #ifdef in vala und also support the still common older libnotify. Unfortunately libnotify just broke and both versions can't be parallel installed. And Fedora seems to be the only distro at the moment, which can use the new libnotify, and does not require the old one to be around. libnotify 0.7 does not require gtk at all. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: allow building without libnotify
On Wed, Nov 24, 2010 at 9:20 AM, Thierry Reding thierry.red...@avionic-design.de wrote: * Matthias Clasen wrote: On Wed, Nov 24, 2010 at 5:57 AM, Kay Sievers kay.siev...@vrfy.org wrote: On Wed, Nov 24, 2010 at 08:36, Thierry Reding thierry.red...@avionic-design.de wrote: This patch makes the libnotify dependency optional and doesn't build the systemd-gnome-ask-password-agent utility if libnotify is not available. Since libnotify = 0.7.0 requires gtk+-3.0, this patch may be useful for environments where upgrading Gtk is not an option. Yeah, would be good to solve that. Maybe that's the simplest way to do it. One other option would be to use some #ifdef in vala und also support the still common older libnotify. Unfortunately libnotify just broke and both versions can't be parallel installed. And Fedora seems to be the only distro at the moment, which can use the new libnotify, and does not require the old one to be around. libnotify 0.7 does not require gtk at all. Well, the tests need gtk, so perhaps libnotify's configure script needs a --disable-tests option so it can be built without the gtk dependency. Will you accept a patch? Thats just a build dependency, but sure, why not. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: allow building without libnotify
On Wed, Nov 24, 2010 at 9:21 AM, Kay Sievers kay.siev...@vrfy.org wrote: libnotify 0.7 does not require gtk at all. Hmm, whatever it is, there is an incompatible change, and the old an the new version can not be installed in parallel, isn't it? And all others besides Fedora are stuck with the old version which does not work with the code in systemd, right? Yes. There's an area of diminishing returns when making things parallel installable. You don't want teeny, unstable libraries to grow parallel versions, really. In this case, we decided for one-time porting pain. Of course, distributions may still decide the other way, and introduce a libnotify06 package... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] building against libnotify 0.7
Here are two patches I needed to get systemd to build against the
current libnotify and vala releases.
diff -up systemd-11/src/ask-password-agent.vala.notify systemd-11/src/ask-password-agent.vala
--- systemd-11/src/ask-password-agent.vala.notify 2010-11-12 20:27:39.535719001 -0500
+++ systemd-11/src/ask-password-agent.vala 2010-11-12 20:27:52.233719001 -0500
@@ -181,8 +181,7 @@ public class MyStatusIcon : StatusIcon {
set_visible(true);
-Notification n = new Notification(title, message, icon, null);
-n.attach_to_status_icon(this);
+Notification n = new Notification(title, message, icon);
n.set_timeout(5000);
n.show();
diff -up systemd-11/src/ask-password-agent.vala.vala-build systemd-11/src/ask-password-agent.vala
--- systemd-11/src/ask-password-agent.vala.vala-build 2010-11-12 20:51:53.579719000 -0500
+++ systemd-11/src/ask-password-agent.vala 2010-11-12 20:52:06.288719002 -0500
@@ -225,7 +225,7 @@ public class MyStatusIcon : StatusIcon {
OutputStream stream = new UnixOutputStream(to_process, true);
-stream.write(password, password.length, null);
+stream.write(password.data, null);
}
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
