[systemd-devel] test-dhcp-client failing in mock builds

2015-01-31 Thread Zbigniew Jędrzejewski-Szmek
Hi,

I was trying to enable tests in the %check part of systemd rpm.
Something strange happens which causes test-dhcp-client when building
in mock:

FAIL: test-dhcp-client
==

Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:141, 
function sd_dhcp_client_set_request_option(). Ignoring.
Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:172, 
function sd_dhcp_client_set_request_address(). Ignoring.
Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:185, 
function sd_dhcp_client_set_index(). Ignoring.
Assertion 'interface_index  0' failed at 
../src/libsystemd-network/sd-dhcp-client.c:188, function 
sd_dhcp_client_set_index(). Ignoring.
Assertion 'interface_index  0' failed at 
../src/libsystemd-network/sd-dhcp-client.c:188, function 
sd_dhcp_client_set_index(). Ignoring.
Assertion 'interface_index  0' failed at 
../src/libsystemd-network/sd-dhcp-client.c:188, function 
sd_dhcp_client_set_index(). Ignoring.
DHCP CLIENT (0x0): FREE
DHCP CLIENT (0x99188836): STARTED on ifindex 42
DHCP CLIENT (0x99188836): DISCOVER
DHCP CLIENT (0x99188836): STOPPED
DHCP CLIENT (0x0): FREE
DHCP CLIENT (0xa71f5099): STARTED on ifindex 42
DHCP CLIENT (0xa71f5099): DISCOVER
DHCP CLIENT (0xa71f5099): OFFER
DHCP CLIENT (0xa71f5099): REQUEST (requesting)
DHCP CLIENT (0xa71f5099): ACK
DHCP CLIENT (0xa71f5099): lease expires in 9min 58.349975s
DHCP CLIENT (0xa71f5099): T2 expires in 8min 43.759020s
DHCP CLIENT (0xa71f5099): T1 expires in 4min 59.245773s
DHCP CLIENT (0xa71f5099): STOPPED: Operation not permitted
Assertion 'event == DHCP_EVENT_IP_ACQUIRE' failed at 
../src/libsystemd-network/test-dhcp-client.c:374, function 
test_addr_acq_acquired(). Aborting.
* test_request_basic
* test_checksum
* test_discover_message
  recv DHCP Discover 0x99188836
* test_addr_acq
  recv DHCP Discover 0xa71f5099
  sent DHCP Offer
  recv DHCP Request  0xa71f5099
  send DHCP Ack

As you can see, stopping fails with EPERM. But when I run it by hand
in the same build root, it works fine. Could this be some kind of race?
I don't know this part of the code at all, so I'm at loss here.

For comparison, the same binary executed by hand:

# ./test-dhcp-client 
* test_request_basic
Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:141, 
function sd_dhcp_client_set_request_option(). Ignoring.
Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:172, 
function sd_dhcp_client_set_request_address(). Ignoring.
Assertion 'client' failed at ../src/libsystemd-network/sd-dhcp-client.c:185, 
function sd_dhcp_client_set_index(). Ignoring.
Assertion 'interface_index  0' failed at 
../src/libsystemd-network/sd-dhcp-client.c:188, function 
sd_dhcp_client_set_index(). Ignoring.
Assertion 'interface_index  0' failed at 
../src/libsystemd-network/sd-dhcp-client.c:188, function 
sd_dhcp_client_set_index(). Ignoring.
Assertion 'interface_index  0' failed at 
../src/libsystemd-network/sd-dhcp-client.c:188, function 
sd_dhcp_client_set_index(). Ignoring.
DHCP CLIENT (0x0): FREE
* test_checksum
* test_discover_message
DHCP CLIENT (0x49229752): STARTED on ifindex 42
  recv DHCP Discover 0x49229752
DHCP CLIENT (0x49229752): DISCOVER
DHCP CLIENT (0x49229752): STOPPED
DHCP CLIENT (0x0): FREE
* test_addr_acq
DHCP CLIENT (0x244b510a): STARTED on ifindex 42
  recv DHCP Discover 0x244b510a
  sent DHCP Offer
DHCP CLIENT (0x244b510a): DISCOVER
DHCP CLIENT (0x244b510a): OFFER
  recv DHCP Request  0x244b510a
  send DHCP Ack
DHCP CLIENT (0x244b510a): REQUEST (requesting)
DHCP CLIENT (0x244b510a): ACK
DHCP CLIENT (0x244b510a): lease expires in 9min 57.257940s
DHCP CLIENT (0x244b510a): T2 expires in 8min 42.525380s
DHCP CLIENT (0x244b510a): T1 expires in 5min 231.299ms
  DHCP address acquired
DHCP CLIENT (0x244b510a): STOPPED
DHCP CLIENT (0x0): FREE

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] User sessions, session buses, user buses

2015-01-31 Thread Simon McVittie
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 ages.

Environment variables are specified by POSIX, also available in Windows,
and one of the few easy ways for information to inherit from a parent
process to a child process without the child process needing to do
anything explicitly. I don't think they're going to go away, however
much you might want them to - the long tail of (mostly TUI) programs
that use them is very long indeed.

I do agree that the number of them that are necessary should go down
over time (and my distro of choice, Debian, has a policy of everything
we ship should be usable without manually setting magic environment
variables), but I don't think it is likely to go down to zero.

 The long-term goal (also in a world where a graphical session is managed
 as a systemd user-session), the information provided until now by an
 environment variable should be queried dynamically by e.g. a D-Bus call
 to the component responsible for providing the relevant information.

Environment variables do several different things.

Having a quick skim through my `env` output, here are some distinct
categories:

We talked about LANG a bit at the hackfest, and the consensus seemed to
be that something better should happen, but nobody was sure exactly
what. I don't set LC_* but if I did, they'd be in the same category.

Losing DBUS_SESSION_BUS_ADDRESS was part of the point of this thread.
:-) Similarly, DISPLAY, GPG_AGENT_INFO, SSH_AUTH_SOCK should be able to
go away one day, when those things grow support for
XDG_RUNTIME_DIR-based socket-activation. XAUTHORITY can go away
eventually too, even in X11 environments, in favour of xhost
+SI:localuser:smcv (which in fact gdm already does).

DEBEMAIL, LESS, LS_COLORS, PYTHONSTARTUP, SHELL, SSH_ASKPASS, VISUAL are
configuration, and could in principle be read from a dotfile instead
(although good luck porting every last consumer of EDITOR, SHELL and
VISUAL to your new world order - e.g. Debian has more than 37k packages).

XDG_SEAT, XDG_SESSION_ID, XDG_VTNR are properties of my login-session,
not my user-session or my home directory, so you can't write them to
either XDG_RUNTIME_DIR or a dotfile because both would be the wrong scope.

XDG_RUNTIME_DIR has to be an environment variable because you can't very
well read it from the XDG_RUNTIME_DIR :-)

S

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] User sessions, session buses, user buses

2015-01-31 Thread Simon McVittie
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 on calling them super-sessions that's fine.

 If people want to put work into this model, we could do a lot better
 than we do now; for instance, the bus socket could be
 unix:path=${XDG_RUNTIME_DIR}/sessions/${XDG_SESSION_ID}/bus (but with
 the necessary escaping) on systems where those variables are set, rather
 than messing about with $TMPDIR.

Please open an enhancement-severity bug against dbus if you want this,
and I can talk you through the right places to patch; it would not be
rocket science, and if people have use-cases for it, I would be OK with
merging it even though I personally prefer the user-session model.

 Similarly, if you leave a screen/tmux session detached and running
 in the background, systemd is fine with that: its view of the world
 is that there are processes left over from your previous login session,
 keeping the login session alive in closing state, with the consequence
 that the user-session remains alive too

Notes from the hackfest: Everyone seems to think screen/tmux/... should
use PAM to register themselves as first-class login sessions in their
own right, if allowed by the sysadmin. That would also work fine.

 Under X11, that might well be the best we can do, because typical
 X11 applications can't cope with being asked to put windows on more
 than one $DISPLAY (although I've heard rumours that Emacs can, which
 would make Emacs an ideal candidate to be a user-session service).
 Under Wayland or similar future cleverness, hopefully there'll be
 some way for a new login on a new seat to steal all the windows
 from the inactive seat, or some way to merge both seats into
 one big virtual display if the same person is using both (AIUI this
 is what GNOME designers want to do), or some other clever solution.

Notes from the hackfest: Lennart's long-term idea is to have a singleton
X server (or Wayland equivalent) per uid, and hotplug output devices
to it as the user logs in/out on different seats (or remotely via RFB or
whatever), with the ability to clone the same window layout onto all
displays, or have distinct displays and move windows between them, a lot
like the way we currently deal with multiple monitors per seat. This
also solves the $DISPLAY problem rather nicely.

Regards,
S

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] backlight: let udev properties override clamping

2015-01-31 Thread Topi Miettinen
On 01/29/15 00:09, Lennart Poettering wrote:
 On Wed, 28.01.15 23:51, Topi Miettinen (toiwo...@gmail.com) wrote:
 
 diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
 index 1271a66..df53b75 100644
 --- a/src/backlight/backlight.c
 +++ b/src/backlight/backlight.c
 @@ -373,6 +373,7 @@ int main(int argc, char *argv[]) {
  
  if (streq(argv[1], load)) {
  _cleanup_free_ char *value = NULL;
 +const char *clamp;
  
  if (!shall_restore_state())
  return EXIT_SUCCESS;
 @@ -390,7 +391,9 @@ int main(int argc, char *argv[]) {
  return EXIT_FAILURE;
  }
  
 -clamp_brightness(device, value, max_brightness);
 +clamp = udev_device_get_property_value(device, 
 ID_BACKLIGHT_CLAMP);
 +if (clamp == NULL || streq(clamp, 1))
 
 Please use parse_boolean() for this.

OK.

 
 I think it would be better to name this ID_BACKLIGHT_CLAMP_MIN or so.

_MIN as in minimum? The brightness is also clamped to maximum brightness
advertised by the device.

-Topi

 
 Otherwise looks fine to me.
 
 Lennart
 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Support for staged startup

2015-01-31 Thread Alison Chaiken
I asked:
 I don't know of any use case for one unit to start another directly.
 Is there one?

Marko responds:
 1.) Coming up with a small tree first reduces the loading time of the unit 
 set (not so much important in my case)

 2.) If you wanna create some dynamics between target A and target B so that 
 depending on the startup situation services are already started before A or 
 in another round they are delayed until A is done, you probably need to 
 disconnect them from the static startup tree and pull them in dynamically at 
 the desired time.

systemd includes 19 conditionals (see './systemd
--dump-configuration-items | grep Cond').The first, static set of
services can therefore use a variety of signals like symlinks or file
modification times to signal the second wave of services.You
could, for example, write a script to dynamically change where
default.target points depending on whether ConditionKernelCommandLine
contains certain bootargs or ConditionFirstBoot is TRUE.   These
signals are in addition to the more usual ones implemented by
sd_notify().

If there's a real need to check a different type of Condition, it
would be more in keeping with the spirit of systemd to add the new
Condition functionality than to have one unit specifically invoke
another.

-- Alison

-- 
Alison Chaiken   ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals.  -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [RFC PATCH 1/2] Add language fallback map

2015-01-31 Thread Zbigniew Jędrzejewski-Szmek
From: Naveen Kumar nku...@redhat.com

This map will be used to provide a fallback for translations.
For example, a Niederdeutsch (nds) speaker prefers to fall back to
German (de) translations rather then the English (C) ones.

https://bugzilla.redhat.com/show_bug.cgi?id=624158#c9
---
 src/locale/language-fallback-map | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 src/locale/language-fallback-map

diff --git a/src/locale/language-fallback-map b/src/locale/language-fallback-map
new file mode 100644
index 00..8b7532fb63
--- /dev/null
+++ b/src/locale/language-fallback-map
@@ -0,0 +1,6 @@
+en_AU en_AU:en_GB
+en_IE en_IE:en_GB
+en_NZ en_NZ:en_GB
+en_ZA en_ZA:en_GB
+mai_IN mai:hi
+nds_DE nds:de
-- 
2.1.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [RFC PATCH 2/2] localed: add LANGUAGE= fallback when LANG= is specified

2015-01-31 Thread Zbigniew Jędrzejewski-Szmek
For the entries listed in the first column of language-fallback-map,
the entry from the second column will be used for LANGUAGE=, if
LANGUAGE= is not explicitly specified.

https://bugzilla.redhat.com/show_bug.cgi?id=624158
---
This fixes a long-standing bug where users of a dialect locale would like
to fallback to a more general one for translations. For example, zh_HK to
zh_CN, etc.

I think the implementation is fine, since it is rather trivial, but I'm
less certain about the implications of setting LANGUAGE in addtion to
LANG.

Zbyszek


 Makefile.am  |  1 +
 src/locale/localed.c | 76 +---
 2 files changed, 68 insertions(+), 9 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e3ba11c8c0..f359da7154 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -190,6 +190,7 @@ AM_CPPFLAGS = \
-DSYSTEM_SHUTDOWN_PATH=\$(systemshutdowndir)\ \
-DSYSTEM_SLEEP_PATH=\$(systemsleepdir)\ \
-DSYSTEMD_KBD_MODEL_MAP=\$(pkgdatadir)/kbd-model-map\ \
+   -DSYSTEMD_LANGUAGE_FALLBACK_MAP=\$(pkgdatadir)/language-fallback-map\ 
\
-DX_SERVER=\$(bindir)/X\ \
-DUDEVLIBEXECDIR=\$(udevlibexecdir)\ \
-DPOLKIT_AGENT_BINARY_PATH=\$(bindir)/pkttyagent\ \
diff --git a/src/locale/localed.c b/src/locale/localed.c
index 529a9abfd6..3a11992f6a 100644
--- a/src/locale/localed.c
+++ b/src/locale/localed.c
@@ -512,7 +512,9 @@ static const char* strnulldash(const char *s) {
 return isempty(s) || streq(s, -) ? NULL : s;
 }
 
-static int read_next_mapping(FILE *f, unsigned *n, char ***a) {
+static int read_next_mapping(const char* filename,
+ unsigned min_fields, unsigned max_fields,
+ FILE *f, unsigned *n, char ***a) {
 assert(f);
 assert(n);
 assert(a);
@@ -521,6 +523,7 @@ static int read_next_mapping(FILE *f, unsigned *n, char 
***a) {
 char line[LINE_MAX];
 char *l, **b;
 int r;
+size_t length;
 
 errno = 0;
 if (!fgets(line, sizeof(line), f)) {
@@ -541,8 +544,9 @@ static int read_next_mapping(FILE *f, unsigned *n, char 
***a) {
 if (r  0)
 return r;
 
-if (strv_length(b)  5) {
-log_error(Invalid line SYSTEMD_KBD_MODEL_MAP:%u, 
ignoring., *n);
+length = strv_length(b);
+if (length  min_fields || length  max_fields) {
+log_error(Invalid line %s:%u, ignoring., filename, 
*n);
 strv_free(b);
 continue;
 
@@ -579,7 +583,7 @@ static int vconsole_convert_to_x11(Context *c, sd_bus *bus) 
{
 _cleanup_strv_free_ char **a = NULL;
 int r;
 
-r = read_next_mapping(f, n, a);
+r = read_next_mapping(SYSTEMD_KBD_MODEL_MAP, 5, 
UINT_MAX, f, n, a);
 if (r  0)
 return r;
 if (r == 0)
@@ -677,7 +681,7 @@ static int find_legacy_keymap(Context *c, char 
**new_keymap) {
 _cleanup_strv_free_ char **a = NULL;
 unsigned matching = 0;
 
-r = read_next_mapping(f, n, a);
+r = read_next_mapping(SYSTEMD_KBD_MODEL_MAP, 5, UINT_MAX, f, 
n, a);
 if (r  0)
 return r;
 if (r == 0)
@@ -752,6 +756,35 @@ static int find_legacy_keymap(Context *c, char 
**new_keymap) {
 return 0;
 }
 
+static int find_language_fallback(const char *lang, char **language) {
+_cleanup_fclose_ FILE *f = NULL;
+unsigned n = 0;
+
+assert(language);
+
+f = fopen(SYSTEMD_LANGUAGE_FALLBACK_MAP, re);
+if (!f)
+return -errno;
+
+for (;;) {
+_cleanup_strv_free_ char **a = NULL;
+int r;
+
+r = read_next_mapping(SYSTEMD_LANGUAGE_FALLBACK_MAP, 2, 2, f, 
n, a);
+if (r = 0)
+return r;
+
+if (streq(lang, a[0])) {
+assert(strv_length(a) == 2);
+*language = a[1];
+a[1] = NULL;
+return 1;
+}
+}
+
+assert_not_reached(should not be here);
+}
+
 static int x11_convert_to_vconsole(Context *c, sd_bus *bus) {
 bool modified = false;
 int r;
@@ -841,9 +874,10 @@ static int method_set_locale(sd_bus *bus, sd_bus_message 
*m, void *userdata, sd_
 Context *c = userdata;
 _cleanup_strv_free_ char **l = NULL;
 char **i;
+const char *lang = NULL;
 int interactive;
 bool modified = false;
-bool passed[_LOCALE_MAX] = {};
+bool have[_LOCALE_MAX] = {};
 int p;
 int r;
 
@@ -867,7 +901,10 

Re: [systemd-devel] [PATCH] timesyncd: Make saving clock to disk on NTP fix optional

2015-01-31 Thread Zbigniew Jędrzejewski-Szmek
Kay, Lennart,
comments?

Zbyszek

On Thu, Jan 29, 2015 at 09:27:38AM +0100, Philipp Reinkemeier wrote:
 Hi.
 
 Since it has bothered me that systemd-timesyncd unconditionally writes
 the current clock value to disk everytime it got an NTP fix i filed a
 BUG report (https://bugs.freedesktop.org/show_bug.cgi?id=86292).
 Zbigniew asked me to send a patch to this mailing list. So here it
 is. I also attached it to the BUG report mentioned above.
 
 Philipp
 -- 
 Dipl.-Inform. Philipp Reinkemeier
 OFFIS e.V.
 Escherweg 2, D-26121 Oldenburg, Germany
 Phone: +49 441 9722-400
 E-Mail: philipp.reinkeme...@offis.de
 PGP: 0x2DA75A6F or 0xCCB2AF14

 From 8c03d37688a6163bdd0a7a6379b18f8c3c7a501b Mon Sep 17 00:00:00 2001
 From: Philipp Reinkemeier philipp.reinkeme...@offis.de
 Date: Wed, 28 Jan 2015 14:53:07 +0100
 Subject: [PATCH] timesyncd: Make saving clock to disk on NTP fix optional
 
 This introduces a new property SaveClockOnNtpFix in the
 timesyncd.conf configuration file. It takes a boolean value.
 If we get an NTP, the clock is saved to disk depending on that
 value.
 
 Previously, the clock was saved on every NTP fix. This commit
 preserves this default behavior. If SaveClockOnNtpFix is disabled,
 then the clock is only saved during shutdown of systemd-timesyncd.
 This can be useful if one wants to keep disk accesses at a minimum
 (save power, prevents disk spin-ups to improve their lifetime).
 ---
  man/timesyncd.conf.xml | 14 ++
  src/timesync/timesyncd-gperf.gperf |  7 ---
  src/timesync/timesyncd-manager.c   |  5 -
  src/timesync/timesyncd-manager.h   |  2 ++
  src/timesync/timesyncd.conf.in |  1 +
  5 files changed, 25 insertions(+), 4 deletions(-)
 
 diff --git a/man/timesyncd.conf.xml b/man/timesyncd.conf.xml
 index 1a56c2c..9a93737 100644
 --- a/man/timesyncd.conf.xml
 +++ b/man/timesyncd.conf.xml
 @@ -105,6 +105,20 @@
  used instead./para/listitem
  /varlistentry
  
 +varlistentry
 +
 termvarnameSaveClockOnNtpFix=/varname/term
 +listitemparaTakes a boolean value. If 
 enabled
 +(the default), then everytime an NTP fix is 
 acquired,
 +the new clock value is written to disk (the 
 file
 +filename/var/lib/systemd/clock/filename 
 is touched).
 +The date of that file is used upon startup of
 +commandsystemd-timesyncd/command to 
 initialize
 +the system clock (useful for systems that 
 lack an RTC).
 +If not enabled, then the clock value is only 
 written
 +to disk upon shutdown of
 +
 commandsystemd-timesyncd/command./para/listitem
 +/varlistentry
 +
  /variablelist
  /refsect1
  
 diff --git a/src/timesync/timesyncd-gperf.gperf 
 b/src/timesync/timesyncd-gperf.gperf
 index 29a2cfe..03dc828 100644
 --- a/src/timesync/timesyncd-gperf.gperf
 +++ b/src/timesync/timesyncd-gperf.gperf
 @@ -14,6 +14,7 @@ struct ConfigPerfItem;
  %struct-type
  %includes
  %%
 -Time.NTP,   config_parse_servers, SERVER_SYSTEM,   0
 -Time.Servers,   config_parse_servers, SERVER_SYSTEM,   0
 -Time.FallbackNTP,   config_parse_servers, SERVER_FALLBACK, 0
 +Time.NTP,   config_parse_servers, SERVER_SYSTEM,   0
 +Time.Servers,   config_parse_servers, SERVER_SYSTEM,   0
 +Time.FallbackNTP,   config_parse_servers, SERVER_FALLBACK, 0
 +Time.SaveClockOnNtpFix, config_parse_bool,0,   
 offsetof(Manager, save_clock_on_ntp_fix)
 diff --git a/src/timesync/timesyncd-manager.c 
 b/src/timesync/timesyncd-manager.c
 index bc35662..cf05a20 100644
 --- a/src/timesync/timesyncd-manager.c
 +++ b/src/timesync/timesyncd-manager.c
 @@ -378,7 +378,8 @@ static int manager_adjust_clock(Manager *m, double 
 offset, int leap_sec) {
  if (r  0)
  return r;
  
 -touch(/var/lib/systemd/clock);
 +if (m-save_clock_on_ntp_fix)
 +touch(/var/lib/systemd/clock);
  
  m-drift_ppm = tmx.freq / 65536;
  
 @@ -1118,6 +1119,8 @@ int manager_new(Manager **ret) {
  
  RATELIMIT_INIT(m-ratelimit, RATELIMIT_INTERVAL_USEC, 
 RATELIMIT_BURST);
  
 +m-save_clock_on_ntp_fix = true;
 +
  r = manager_parse_server_string(m, SERVER_FALLBACK, NTP_SERVERS);
  if (r  0)
  return r;
 diff --git a/src/timesync/timesyncd-manager.h 
 b/src/timesync/timesyncd-manager.h
 index c7efdc5..4cc1a31 100644
 --- a/src/timesync/timesyncd-manager.h
 +++ b/src/timesync/timesyncd-manager.h
 @@ -40,6 +40,8 @@ struct Manager {
  LIST_HEAD(ServerName, link_servers);
  LIST_HEAD(ServerName, fallback_servers);
  
 +

Re: [systemd-devel] [PATCH] man: typos in systemd-network.xml regarding DHCP

2015-01-31 Thread Zbigniew Jędrzejewski-Szmek
On Sat, Jan 31, 2015 at 04:16:12PM -0800, Brian Redbeard wrote:
 In the systemd documentation for systemd.network units the
 [Network] section notes that for the option DHCP=:
 
 DHCP=
 Enables DHCPv4 and/or DHCPv6 support. Accepts yes, no, ipv4
 or ipv6.
 
 In testing the options ipv4 and ipv6 are actually implemented as
 v4 and v6.  Additionally on the same page in Example 2 the sample is
 give:
 
 [Network]
 DHCP=both
 
 which is not referenced in the above option.
 
Frankly, I'm not sure if the man page should be changed to match the code or the
other way around.

Zbyszek

 ---
  man/systemd.network.xml | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/man/systemd.network.xml b/man/systemd.network.xml
 index c072f08..59bee9c 100644
 --- a/man/systemd.network.xml
 +++ b/man/systemd.network.xml
 @@ -220,8 +220,8 @@
  termvarnameDHCP=/varname/term
  listitem
  paraEnables DHCPv4 and/or 
 DHCPv6 support. Accepts
 -literalyes/literal, 
 literalno/literal,
 -literalipv4/literal or 
 literalipv6/literal./para
 +literalyes/literal, 
 literalno/literal, literalboth/literal,
 +literalv4/literal or 
 literalv6/literal./para
  /listitem
  /varlistentry
  varlistentry
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] man: typos in systemd-network.xml regarding DHCP

2015-01-31 Thread Brian Redbeard
In the systemd documentation for systemd.network units the
[Network] section notes that for the option DHCP=:

DHCP=
Enables DHCPv4 and/or DHCPv6 support. Accepts yes, no, ipv4
or ipv6.

In testing the options ipv4 and ipv6 are actually implemented as
v4 and v6.  Additionally on the same page in Example 2 the sample is
give:

[Network]
DHCP=both

which is not referenced in the above option.

Signed-off-by: Brian 'Redbeard' Harrington redbe...@dead-city.org
---
 man/systemd.network.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index c072f08..59bee9c 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -220,8 +220,8 @@
 termvarnameDHCP=/varname/term
 listitem
 paraEnables DHCPv4 and/or 
DHCPv6 support. Accepts
-literalyes/literal, 
literalno/literal,
-literalipv4/literal or 
literalipv6/literal./para
+literalyes/literal, 
literalno/literal, literalboth/literal,
+literalv4/literal or 
literalv6/literal./para
 /listitem
 /varlistentry
 varlistentry
-- 
1.9.3

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] backlight: let udev properties override clamping

2015-01-31 Thread Topi Miettinen
On my computer, the minimum brightness enforced by clamping in
backlight is too bright.

Let udev property ID_BACKLIGHT_CLAMP control whether the brightness
is clamped or not.
---
 man/systemd-backli...@.service.xml | 9 -
 src/backlight/backlight.c  | 5 -
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/man/systemd-backli...@.service.xml 
b/man/systemd-backli...@.service.xml
index 453afbf..21c6437 100644
--- a/man/systemd-backli...@.service.xml
+++ b/man/systemd-backli...@.service.xml
@@ -58,7 +58,14 @@
 is a service that restores the display backlight
 brightness at early boot and saves it at shutdown. On
 disk, the backlight brightness is stored in
-filename/var/lib/systemd/backlight//filename./para
+filename/var/lib/systemd/backlight//filename. During
+loading, if udev property
+optionID_BACKLIGHT_CLAMP/option is not set to
+false value, the brightness is clamped to a value of
+at least 1 or 5% of maximum brightness, whichever is
+greater. This restriction will be removed when the
+kernel allows user space to reliably set a brightness
+value which does not turn off the display./para
 /refsect1
 
 refsect1
diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 1271a66..2d357db 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -373,6 +373,7 @@ int main(int argc, char *argv[]) {
 
 if (streq(argv[1], load)) {
 _cleanup_free_ char *value = NULL;
+const char *clamp;
 
 if (!shall_restore_state())
 return EXIT_SUCCESS;
@@ -390,7 +391,9 @@ int main(int argc, char *argv[]) {
 return EXIT_FAILURE;
 }
 
-clamp_brightness(device, value, max_brightness);
+clamp = udev_device_get_property_value(device, 
ID_BACKLIGHT_CLAMP);
+if (clamp == NULL || parse_boolean(clamp))
+clamp_brightness(device, value, max_brightness);
 
 r = udev_device_set_sysattr_value(device, brightness, value);
 if (r  0) {
-- 
2.1.4

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] backlight: let udev properties override clamping

2015-01-31 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Jan 28, 2015 at 11:51:47PM +0200, Topi Miettinen wrote:
 On my computer, the minimum brightness enforced by clamping in
 backlight is too bright.
 
 Let udev property ID_BACKLIGHT_CLAMP control whether the brightness
 is clamped or not.
 ---
  man/systemd-backli...@.service.xml | 11 ++-
  src/backlight/backlight.c  |  5 -
  2 files changed, 14 insertions(+), 2 deletions(-)
 
 diff --git a/man/systemd-backli...@.service.xml 
 b/man/systemd-backli...@.service.xml
 index 453afbf..4105685 100644
 --- a/man/systemd-backli...@.service.xml
 +++ b/man/systemd-backli...@.service.xml
 @@ -58,7 +58,16 @@
  is a service that restores the display backlight
  brightness at early boot and saves it at shutdown. On
  disk, the backlight brightness is stored in
 -filename/var/lib/systemd/backlight//filename./para
 +filename/var/lib/systemd/backlight//filename. During
 +loading, if udev property ID_BACKLIGHT_CLAMP is not
 +present or is set to literal1/literal, the
 +brightness is clamped to at least value
 +literal1/literal or 5% of maximum brightness. This
 +is to avoid an unpowered display due to poor API
 +design in kernel (unfixed as of 2015-01-28) that does
 +not allow user space to know the difference between
 +lowest brightness and powering off the
 +backlight./para
Since you're going to submit a new version anyway, please reword this bit.
Maybe something like this:

  During loading, if udev property optionID_BACKLIGHT_CLAMPoption
  is not set to a false value, brightness is clamped to a value of at
  least 1 or 5% of the maximum brightness, whichever is greater. This
  restriction will be removed when the kernel allows user space to
  reliably set a brightness value which does not turn off the display.

Zbyszek

  /refsect1
  
  refsect1
 diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
 index 1271a66..df53b75 100644
 --- a/src/backlight/backlight.c
 +++ b/src/backlight/backlight.c
 @@ -373,6 +373,7 @@ int main(int argc, char *argv[]) {
  
  if (streq(argv[1], load)) {
  _cleanup_free_ char *value = NULL;
 +const char *clamp;
  
  if (!shall_restore_state())
  return EXIT_SUCCESS;
 @@ -390,7 +391,9 @@ int main(int argc, char *argv[]) {
  return EXIT_FAILURE;
  }
  
 -clamp_brightness(device, value, max_brightness);
 +clamp = udev_device_get_property_value(device, 
 ID_BACKLIGHT_CLAMP);
 +if (clamp == NULL || streq(clamp, 1))
 +clamp_brightness(device, value, max_brightness);
  
  r = udev_device_set_sysattr_value(device, brightness, 
 value);
  if (r  0) {
 -- 
 2.1.4
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-01-31 Thread John Lane
On 30/01/15 09:49, Jan Janssen wrote:

 But really: why not use automounting logic in fstab?:
 /dev/mapper/data /home/myuser/data ext4 noauto,x-systemd.automount 0 0

 No need to manually trigger a mount. And you can even use noauto in
 crypttab so that the encrypted device is only opened once the mount point is
 accessed the first time.
Thanks Jan. as it happens, I've just been trying automount as a solution
before I read your answer ;)

But it leads me on to another question, if that's ok...

I've set up an encrypted volume configured in crypttab/fstab with
key/header on a path that is automounted.
That path is on a encrypted removable usb keyring that's inserted at
boot and everything works: the keyring is unlocked (passphrase
requested) and mounted and then the other volumes are unlocked using
their key/header on the keyring and mounted.

However, after boot I want to pull out the keyring (it's only needed for
the key/header during systemd-cryptsetup).
But when I do this, the encrypted volume is unmounted and I don't want
this to happen.

Here's what I have in crypttab:

|# name  device   password options
keyring   PARTLABEL=keyring  none   noauto
abc   /dev/lvm/abc   /root/keyring/abc.key  header=/root/keyring/abc.hdr
xyz   /dev/lvm/xyz   /root/keyring/xyz.key  
header=/root/keyring/xyz.hdr|


and fstab:

| file system dir typeoptions
/dev/mapper/keyring /root/keyring ext4  ro,noauto,x-systemd.automount
/dev/mapper/abc /srv/abc  ext4
/dev/mapper/xyz /srv/xyz  ext4|


I don't want to lose abc and xyz when I pull out keyring.

I think it might be due to the RequiresMountsFor=/root/keyring/abc.key
entries that systemd generates in the cryptsetup unit.
I have tried using a drop-in to cancel that option:

[Unit]
RequiresMountsFor=

but that didn't affect the setting, as I verified with

$ systemctl daemon-reload
$ systemctl show systemd-cryptsetup\@abc --property RequiresMountsFor
RequiresMountsFor=/root/keyring/abc.key

Do you know if/how I can achieve this functionality?

Much appreciated,
John


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

2015-01-31 Thread John Lane
On 31/01/15 10:25, John Lane wrote:
 On 30/01/15 09:49, Jan Janssen wrote:

 But really: why not use automounting logic in fstab?:
 /dev/mapper/data /home/myuser/data ext4 noauto,x-systemd.automount 0 0

 No need to manually trigger a mount. And you can even use noauto in
 crypttab so that the encrypted device is only opened once the mount point is
 accessed the first time.
 Thanks Jan. as it happens, I've just been trying automount as a
 solution before I read your answer ;)

 But it leads me on to another question, if that's ok...

 I've set up an encrypted volume configured in crypttab/fstab with
 key/header on a path that is automounted.
 That path is on a encrypted removable usb keyring that's inserted at
 boot and everything works: the keyring is unlocked (passphrase
 requested) and mounted and then the other volumes are unlocked using
 their key/header on the keyring and mounted.

 However, after boot I want to pull out the keyring (it's only needed
 for the key/header during systemd-cryptsetup).
 But when I do this, the encrypted volume is unmounted and I don't want
 this to happen.

 Here's what I have in crypttab:

 |# name  device   password options
 keyring   PARTLABEL=keyring  none   noauto
 abc   /dev/lvm/abc   /root/keyring/abc.key  
 header=/root/keyring/abc.hdr
 xyz   /dev/lvm/xyz   /root/keyring/xyz.key  
 header=/root/keyring/xyz.hdr|

 and fstab:

 | file system dir typeoptions
 /dev/mapper/keyring /root/keyring ext4  ro,noauto,x-systemd.automount
 /dev/mapper/abc /srv/abc  ext4
 /dev/mapper/xyz /srv/xyz  ext4|

 I don't want to lose abc and xyz when I pull out keyring.

 I think it might be due to the
 RequiresMountsFor=/root/keyring/abc.key entries that systemd
 generates in the cryptsetup unit.
 I have tried using a drop-in to cancel that option:

 [Unit]
 RequiresMountsFor=

 but that didn't affect the setting, as I verified with

 $ systemctl daemon-reload
 $ systemctl show systemd-cryptsetup\@abc --property RequiresMountsFor
 RequiresMountsFor=/root/keyring/abc.key

 Do you know if/how I can achieve this functionality?

 Much appreciated,
 John




 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Further to this, I tried manually creating a systemd-cryptsetup unit
instead of putting an entry in /etc/crypttab.
This allowed me to remove the RequiresMountsFor entry.

By doing this, removing the keyring doesn't unmount the encrypted volumes.

The unit I used looks like this:
/etc/systemd/system/systemd-cryptsetup@.service

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8)
man:systemd-cryptsetup@.service(8)
#SourcePath=/etc/crypttab
DefaultDependencies=no
Conflicts=umount.target
BindsTo=dev-mapper-%i.device
IgnoreOnIsolate=true
After=cryptsetup-pre.target
Before=cryptsetup.target
#RequiresMountsFor=/root/keyring//%i.key
BindsTo=dev-lvm-%i.device
After=dev-lvm-%i.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach '%i'
'/dev/lvm/%i' '/root/keyring/%i.key' 'header=/root/keyring/%i.hdr'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach '%i'

[Install]
WantedBy=dev-mapper-%i.device

I wonder if it's possible for an /etc/crypttab option to soften the
requirement for the mount to something like StartRequiresMountsFor...




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel