Re: [systemd-devel] suspend hook as user service

[Reverend Homer]

Hi Michael,

thank you for feedback, but you described *system* service and this is the way
I solved my issue for now. The original message was about *user* service — the
service that you can put at $HOME/.config/systemd/user and activate with:

systemctl --user enable myservice.service

R.H.

On Fri, Feb 17, 2017 at 07:41:00PM +0100, Michael Hirmke wrote:
> Hi,
> 
> >Hi,
> 
> >is there any way to start user service before/after suspend.target? In
> >wiki.archlinux.org there are only system sleep hooks [1]. I tried to lock the
> 
> yes, but they also describe, how you can add a system service handling
> special user things.
> 
> [...]
> 
> You can create a service named for example "suspend_user@.service":
> 
> < snip snip snip >-
> [Unit]
> Description=User suspend actions for KDE
> After=sleep.target remote-fs.target
> Requires=remote-fs.target
> StopWhenUnneeded=yes
> 
> [Service]
> User=%I
> Type=oneshot
> ExecStart=...
> TimeoutSec=300
> 
> [Install]
> WantedBy=sleep.target
> < snip snip snip >-
> 
> And enable it with:
> systemctl enable suspend_user@.service.
> 
> It worked for me for a while.
> 
> A much better approach is to write a script or program listening for the
> according signals "PrepareForSleep" and "PrepareForShutdown" on the dbus
> interface "org.freedesktop.login1".
> You can start it for example in your .bashrc or in the KDE startup
> routines.
> 
> 
> >R.H.
> 
> Bye.
> Michael.
> -- 
> Michael Hirmke
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] suspend hook as user service

[Reverend Homer]

Hi,

is there any way to start user service before/after suspend.target? In
wiki.archlinux.org there are only system sleep hooks [1]. I tried to lock the
screen before suspend and put the service inspired by [2] in
~/.config/systemd/user/. But this service just did not start.

R.H.

[1] 
https://wiki.archlinux.org/index.php/Power_management#Suspend.2Fresume_service_files
[2] https://bbs.archlinux.org/viewtopic.php?id=163281
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd

[Reverend Homer]

Hi,

09.10.2015 11:45, yan...@iscas.ac.cn пишет:


Hello guys:
 I have a question. If I want use systemd in my system,like mint 17
,what should I do?

Please, don't use devel mailing list for such questions.
If you want to install systemd on linux mint, you should do something 
like this: 
http://superuser.com/questions/917804/switching-to-systemd-on-linux-mint

or this: https://wiki.ubuntu.com/systemd
Or you can install the distro with systemd by default. For example, 
Ubuntu 15.04 has systemd as default init, AFAIK.


yan...@iscas.ac.cn


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



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

Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker

[Reverend Homer]

29.07.2015 14:40, SF Markus Elfring пишет:

This is *very* strange. The 'format' parameter should not contain that
"%s:%s:%d" prefix at all, as this cannot work of course because the
argument list doesn't match.

I guess that I wonder also about one of my own programming mistakes here.



Which version of systemd are you based on?

last commit: 6ad6d61f9ddd58983b075e4fbece30bae46fac37



Do you have *any* local modifications in your tree?

Yes. - It seems that I was bitten by a format string mismatch during
an attempt to display a few more implementation details for my needs.


diff --git a/src/libsystemd/sd-device/device-private.c 
b/src/libsystemd/sd-device/device-private.c
index 2e60433..b5a31ec 100644
--- a/src/libsystemd/sd-device/device-private.c
+++ b/src/libsystemd/sd-device/device-private.c
@@ -1076,7 +1076,7 @@ int device_update_db(sd_device *device) {
  goto fail;
  }
  
-log_debug("created %s file '%s' for '%s'", has_info ? "db" : "empty",

+log_debug("%s:%s:%d: created %s file '%s' for '%s'", has_info ? "db" : 
"empty", __FUNCTION__, __FILE__, __LINE__,

I think that you mean

+log_debug("%s:%s:%d: created %s file '%s' for '%s'", __FUNCTION__, 
__FILE__, __LINE__,
has_info ? "db" : "empty",


path, device->devpath);
  
  return 0;




Should my compiler "gcc 5.2.0" be able to detect and warn about misplaced
parameters in such an use case?

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


--
Regards,
R.H.

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

Re: [systemd-devel] Visible pull requests on github? [was: [PATCH] mount-setup: create /run/systemd/netif/links/ before accessing]

[Reverend Homer]

02.06.2015 6:56, Martin Pitt пишет:

Hello all,

systemd github import bot [2015-06-01 20:06 -]:

Patchset imported to github.
Pull request:


I've seen these "imported into github" messages for quite a while, but
why don't these actually appear on

   https://github.com/systemd-devs/systemd/pulls

? This only has three (open) pull requests.
It appears in 
https://github.com/systemd-mailing-devs/systemd-mailing-list, and not as 
pull request, but active branch

--
R.H.


Thanks,

Martin


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

Re: [systemd-devel] [PATCH 5/5] import/pull-dkr: V2 Image specification + manifest support

[Reverend Homer]

07.05.2015 18:47, Pavel Odvody пишет:

Signed-off-by: Pavel Odvody 
---
  src/import/pull-dkr.c | 531 --
  src/import/pull-dkr.h |  48 -
  2 files changed, 518 insertions(+), 61 deletions(-)

diff --git a/src/import/pull-dkr.c b/src/import/pull-dkr.c
index 0eefec5..408b795 100644
--- a/src/import/pull-dkr.c
+++ b/src/import/pull-dkr.c
@@ -61,9 +61,10 @@ struct DkrPull {
  PullJob *layer_job;
  
  char *name;

-char *tag;
+char *reference;
  char *id;
  
+char *response_digest;

  char *response_token;
  char **response_registries;
  
@@ -87,7 +88,11 @@ struct DkrPull {

  #define PROTOCOL_PREFIX "https://";
  
  #define HEADER_TOKEN "X-Do" /* the HTTP header for the auth token */ "cker-Token:"

-#define HEADER_REGISTRY "X-Do" /*the HTTP header for the registry */ 
"cker-Endpoints:"
+#define HEADER_REGISTRY "X-Do" /* the HTTP header for the registry */ 
"cker-Endpoints:"
+#define HEADER_DIGEST "Do" /* the HTTP header for the manifest digest */ 
"cker-Content-Digest:"
+#define HEADER_USER_AGENT_V2 "User-Agent: do" /* otherwise we get load-balanced(!) to a 
V1 registyry */ "cker/1.6.0"
+#define HEADER_BEARER_REALM "https://auth.doc"; /* URL which we query for a bearer token 
*/ "ker.io/token"
+#define HEADER_BEARER_SERVICE "registry.doc" /* the service we query the token for */ 
"ker.io"
  
  #define LAYERS_MAX 2048
  
@@ -117,7 +122,7 @@ DkrPull* dkr_pull_unref(DkrPull *i) {

  }
  
  free(i->name);

-free(i->tag);
+free(i->reference);
  free(i->id);
  free(i->response_token);
  free(i->response_registries);
@@ -416,10 +421,25 @@ static int dkr_pull_add_token(DkrPull *i, PullJob *j) {
  return 0;
  }
  
+static int dkr_pull_add_bearer_token(DkrPull *i, PullJob *j) {

+const char *t = NULL;
+
+assert(i);
+assert(j);
+
+if (i->response_token)
+t = strjoina("Authorization: Bearer ", i->response_token);
+
+j->request_header = curl_slist_new(HEADER_USER_AGENT_V2, "Accept: 
application/json", t, NULL);
+if (!j->request_header)
+return -ENOMEM;
+
+return 0;
+}
+
  static bool dkr_pull_is_done(DkrPull *i) {
  assert(i);
  assert(i->images_job);
-
  if (i->images_job->state != PULL_JOB_DONE)
  return false;
  
@@ -429,7 +449,7 @@ static bool dkr_pull_is_done(DkrPull *i) {

  if (!i->ancestry_job || i->ancestry_job->state != PULL_JOB_DONE)
  return false;
  
-if (!i->json_job || i->json_job->state != PULL_JOB_DONE)

+if (i->json_job && i->json_job->state != PULL_JOB_DONE)
  return false;
  
  if (i->layer_job && i->layer_job->state != PULL_JOB_DONE)

@@ -441,8 +461,9 @@ static bool dkr_pull_is_done(DkrPull *i) {
  return true;
  }
  
-static int dkr_pull_make_local_copy(DkrPull *i) {

+static int dkr_pull_make_local_copy(DkrPull *i, enum PullStrategy strategy) {
  int r;
+_cleanup_free_ char *p = NULL;
  
  assert(i);
  
@@ -455,10 +476,30 @@ static int dkr_pull_make_local_copy(DkrPull *i) {

  return log_oom();
  }
  
-r = pull_make_local_copy(i->final_path, i->image_root, i->local, i->force_local);

+if (strategy == PULL_V2) {
+r = path_get_parent(i->image_root, &p);
+if (r < 0)
+return r;
+}
+
+r = pull_make_local_copy(i->final_path, p ?: i->image_root, i->local, 
i->force_local);
  if (r < 0)
  return r;
  
+if (strategy == PULL_V2) {

+char **k = NULL;
+STRV_FOREACH(k, i->ancestry) {
+char *d = strjoina(i->image_root, "/.dkr-", *k, NULL);
+r = btrfs_subvol_remove(d, false);
+if (r < 0)
+   return r;
+}
+
+r = rmdir(i->image_root);
+if (r < 0)
+return r;
+}
+
  return 0;
  }
  
@@ -516,6 +557,68 @@ static void dkr_pull_job_on_progress(PullJob *j) {

 
DKR_DOWNLOADING);
  }
  
+static void dkr_pull_job_on_finished_v2(PullJob *j);

+
+static int dkr_pull_pull_layer_v2(DkrPull *i) {
+_cleanup_free_ char *path = NULL;
+const char *url, *layer = NULL;
+int r;
+
+assert(i);
+assert(!i->layer_job);
+assert(!i->temp_path);
+assert(!i->final_path);
+
+for (;;) {
+layer = dkr_pull_current_layer(i);
+if (!layer)
+return 0; /* no more layers */
+
+path = strjoin(i->image_root, "/.dkr-", layer, NULL);
+if (!path)
+return lo

Re: [systemd-devel] [PATCH v2 5/6] udev: builtin-keyboard: add support for EV_ABS_OVERRIDE

[Reverend Homer]

23.03.2015 04:30, Peter Hutterer пишет:

Parse properties in the form
EV_ABS_OVERRIDE_00=""

and apply them to the kernel device. Future processes that open that device
will see the updated EV_ABS range.

This is particularly useful for touchpads that don't provide a resolution in
the kernel driver but can be fixed up through hwdb entries (e.g. bcm5974).

All values in the property are optional, e.g. a string of "::45" is valid to
set the resolution to 45.

The order intentionally orders resolution before fuzz and flat despite it
being the last element in the absinfo struct. The use-case for setting
fuzz/flat is almost non-existent, resolution is probably the most common case
we'll need.
---
Changes to v1:
- merge into the keyboard builtin rather than a separate one
- make the parsing code less copy/paste-ish

I didn't rename the keyboard builtin or merged it with input_id yet, IMO in
both cases the churn of moving rules/hwdbs around is more effort and risk
than the benefit we get from doing so.

  Makefile.am  |  2 +
  hwdb/60-evdev.hwdb   | 37 +
  rules/60-evdev.rules | 14 +++
  src/udev/udev-builtin-keyboard.c | 85 ++--
  4 files changed, 134 insertions(+), 4 deletions(-)
  create mode 100644 hwdb/60-evdev.hwdb
  create mode 100644 rules/60-evdev.rules

diff --git a/Makefile.am b/Makefile.am
index 86bf53d..9f5b4b7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3689,6 +3689,7 @@ dist_udevrules_DATA += \
rules/50-udev-default.rules \
rules/60-block.rules \
rules/60-drm.rules \
+   rules/60-evdev.rules \
rules/60-keyboard.rules \
rules/60-persistent-storage-tape.rules \
rules/60-persistent-input.rules \
@@ -3873,6 +3874,7 @@ dist_udevhwdb_DATA = \
hwdb/20-acpi-vendor.hwdb \
hwdb/20-OUI.hwdb \
hwdb/20-net-ifname.hwdb \
+   hwdb/60-evdev.hwdb \
hwdb/60-keyboard.hwdb \
hwdb/70-mouse.hwdb \
hwdb/70-touchpad.hwdb
diff --git a/hwdb/60-evdev.hwdb b/hwdb/60-evdev.hwdb
new file mode 100644
index 000..0d67f87
--- /dev/null
+++ b/hwdb/60-evdev.hwdb
@@ -0,0 +1,37 @@
+# This file is part of systemd.
+#
+# The lookup keys are composed in:
+#   60-evdev.rules
+#
+# Note: The format of the "evdev:" prefix match key is a
+# contract between the rules file and the hardware data, it might
+# change in later revisions to support more or better matches, it
+# is not necessarily expected to be a stable ABI.
+#
+# Match string formats:
+# evdev:
+# evdev:name::dmi:
+#
+# To add local entries, create a new file
+#   /etc/udev/hwdb.d/61-evdev-local.hwdb
+# and add your rules there. To load the new rules execute (as root):
+#   udevadm hwdb --update
+#   udevadm trigger /dev/input/eventXX
+# where /dev/input/eventXX is the device in question. If in
+# doubt, simply use /dev/input/event* to reload all input rules.
+#
+# If your changes are generally applicable, open a bug report on
+#   http://bugs.freedesktop.org/enter_bug.cgi?product=systemd
+# and include your new rules, a description of the device, and the
+# output of
+#   udevadm info /dev/input/eventXX
+# (or /dev/input/event*).
+#
+# Allowed properties are:
+#EV_ABS_OVERRIDE_=
+#
+# where  is the hexadecimal EV_ABS code as listed in linux/input.h
+# and min, max, res, fuzz, flat are the decimal values to the respective
+# fields of the struct input_absinfo as listed in linux/input.h.
+# If a field is missing the field will be left as-is. Not all fields need to
+# be present. e.g. ::45 sets the resolution to 45 units/mm.
diff --git a/rules/60-evdev.rules b/rules/60-evdev.rules
new file mode 100644
index 000..67308ad
--- /dev/null
+++ b/rules/60-evdev.rules
@@ -0,0 +1,14 @@
+# do not edit this file, it will be overwritten on update
+
+ACTION=="remove", GOTO="evdev_end"
+KERNEL!="event*", GOTO="evdev_end"
+
+# skip later rules when we find something for this input device
+IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=evdev:", \
+  RUN{builtin}+="keyboard", GOTO="evdev_end"
+
+# device matching the input device name and the machine's DMI data
+KERNELS=="input*", IMPORT{builtin}="hwdb 
'evdev:name:$attr{name}:$attr{[dmi/id]modalias}'", \
+  RUN{builtin}+="keyboard", GOTO="evdev_end"
+
+LABEL="evdev_end"
diff --git a/src/udev/udev-builtin-keyboard.c b/src/udev/udev-builtin-keyboard.c
index ed869ff..38ed800 100644
--- a/src/udev/udev-builtin-keyboard.c
+++ b/src/udev/udev-builtin-keyboard.c
@@ -95,6 +95,68 @@ static void map_keycode(int fd, const char *devnode, int 
scancode, const char *k
  log_error_errno(errno, "Error calling EVIOCSKEYCODE on device node 
'%s' (scan code 0x%x, key code %d): %m", devnode, map.scan, map.key);
  }
  
+static inline char* parse_token(const char *current, int32_t *val_out) {

+char *next;
+int32_t val;
+
+if (!current)
+return NULL;
+
+val = strtol(curren