Re: [systemd-devel] [PATCH] Use normal English elide in place of ellipsize
On 4.2.2014 20:43, Lennart Poettering wrote: On Tue, 04.02.14 15:45, Barry Scott (barry.sc...@onelan.co.uk) wrote: On Tue 04 Feb 2014 19:36:34 Andrey Borzenkov wrote: В Tue, 4 Feb 2014 15:31:58 + Barry Scott barry.sc...@onelan.co.uk пишет: Change the messages output and also all internal function names and variables to match. As a non-native English speaker I must admit ellipsize was more understandable. I am not sure I would understand elide if it was not used in this context. Ellipsize is not in any dictionary for any language. Note that ellipsize is what gtk uses for this kind of thing: https://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-ellipsize Pango calls this ellipsize too: https://developer.gnome.org/pango/stable/pango-Layout-Objects.html#pango-layout-set-ellipsize And so does Android: http://developer.android.com/reference/android/widget/TextView.html#setEllipsize%28android.text.TextUtils.TruncateAt%29 Quite frankly, I am pretty strongly against introducing new vocabulary here, if the word ellipsize appears to be pretty universally established for this kind of thing... I mean, this is not something new we are invented, this simply reused pre-existing technical wording... Lennart I am not a native speaker but I understood word ellipsize on the first sight as I've seen/heard word ellipsis before. So IMHO the meaning here is much more obvious then for the word elide. WRT links Lennart sent above I would vote for ellipsizing rather than eliding strings. Vaclav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] tmpfiles: skip the path entirely if configured as type x
On St 11. prosinec 2013, 03:02:48 CET, Lennart Poettering wrote: On Fri, 08.11.13 07:32, Michal Sekletar (msekl...@redhat.com) wrote: On Thu, Nov 07, 2013 at 10:39:19PM +0100, Lennart Poettering wrote: On Wed, 06.11.13 11:18, Michal Sekletar (msekl...@redhat.com) wrote: Type x in tmpfiles configuration accepts shell style globs instead of normal paths. If user uses normal path he might expect that the path will be left untouched. However this is not the case for directories and content of the directory will be cleaned according to the Age parameter, we should rather skip the path entirely in such case. Hi Lennart, Not sure I follow. dir_cleanup() already skips all items listed in the glob hashmap anyway, no? What does your patch add on top of that? In dir_cleanup() we skip if there is an item configured for the path or it matches the glob, however we are doing it on the subpaths of currently processed directory. This won't work in the case mentioned in the commit message. If user wants to exclude path from cleanup entirely he has to use x /path/*, this way all subpaths match the glob. In case of x /path/ no subpath matches such glob and we remove them, hence checking explicitly beforehand. Hope that makes some sense. Nope. Still not following. Can you give an explicit example of a complete but minimal tmpfiles snippet that currently doesn't behave correctly and that does with your patch? Maybe I grok it then! Thanks, Lennart We discussed and tested it here with Michal and Lukas again and came to conclusion the behavior is correct as is. Thanks, Vaclav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: fix selinux check for transient units
Út 19. listopad 2013, 15:16:47 CET, Michal Sekletar napsal:
On Tue, Nov 19, 2013 at 08:54:41AM -0500, Daniel J Walsh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2013 05:45 PM, Michal Sekletar wrote:
On Mon, Nov 18, 2013 at 04:19:20PM -0500, Daniel J Walsh wrote: On
11/16/2013 08:10 AM, Lennart Poettering wrote:
On Thu, 14.11.13 15:43, Daniel J Walsh (dwa...@redhat.com) wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 11/14/2013 12:50 PM, Harald Hoyer wrote:
On 11/05/2013 11:12 PM, Daniel J Walsh wrote:
On 11/05/2013 12:22 PM, Lennart Poettering wrote:
Ok lets add a check that checks for start on a service labeled
with the remote process label, then we can add rules like
allow systemd_logind_t self:service start
Or we can make it simpler and have the local end check against
the init_t process.
allow systemd_logind_t init_t:service start;
Which is probably a better solution, if we have no way of
differentiating the services.
Machineid usually runs as init_t now.
systemd-run runs as the label of the process that executes it,
Usually unconfined_t, and sysadm_t.
has any solution been found for this?
seems like one is needed for
https://bugzilla.redhat.com/show_bug.cgi?id=1008864
I guess the question I have is do you expect a patch from me? Or
are you guys working on it? I would go with the checking based on
process label.
I am hoping for a patch for this!
Thanks,
Lennart
This patch adds a new call for SELINUX_SNAPSHOT_ACCESS_CHECK, because I
believe this error will happen when a snapshot is created. Also now pass
in system when doing a system check, if it is doing a service
check and
does not pass in a unit file we will default the target to the label
that
systemd is running with.
Hi,
Maybe I am missing something but isn't this about transient units in
general, i.e. what about StartTransient()? What is going to change in
this case after applying this patch? tclass will be system since in
SELINUX_ACCESS_CHECK you now pass system as path and you will set
tclass in else branch to system which is afaik same as before.
In the current code, passing a unit_file of NULL (StartTransients has
a NULL
UnitFile) will indicate that it should do a system check. My patch is
intended to change this so a NULL UnitFile will indicate that systemd
should
check the access between the calling process label and the current
process
label for a service access. Where as the SELINUX_ACCESS_CHECK will
now pass
a system flag to the function to make it do a system check.
Hi Dan,
Agreed, I get the idea, but this means that
SELINUX_SNAPSHOT_ACCESS_CHECK should
be performed in StartTransient branch in dbus-manager.c too and macro
should be
probably renamed to something like SELINUX_RUNTIME_UNIT_ACCESS_CHECK.
Hope that makes sense.
Michal
Hi,
I tried to improve Dan's patch, so I added an empty call if selinux is
not supported, renamed the function so it doesn't imply it's only for
snapshots and used it in StartTransient and RemoveSnapshot as well. I
wanted to test it, but I am not sure if the policy is already updated.
Vaclav
On the side note, you forgot to define SELINUX_SNAPSHOT_ACCESS_CHECK as
do {} while (false) in case if we don't HAVE_SELINUX.
It might be the case that I completely misunderstood what's this about,
in such case ignore this email.
Michal
Thanks added SELINUX_SNAPSHOT_ACCESS_CHECK as do {} while (false) in
case if
we don't HAVE_SELINUX.
Updated patch.
snip
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKLbaEACgkQrlYvE4MpobPMMACeNeyrC3OBhx99DZ+JzOtV1ykZ
PvMAoJfiYBoJRBFgh2+FyOV+tNTuojNU
=9I5G
-END PGP SIGNATURE-
From b372b48016f5c015b34db9f53b7a54a64a5a84e8 Mon Sep 17 00:00:00 2001
From: Dan Walsh dwa...@redhat.com
Date: Mon, 18 Nov 2013 15:52:37 -0500
Subject: [PATCH] Fix SELinux check for snapshot and transitent unit
creation.
SELinux does not have a path to check for a snapshot or transient
unit files service creation. Currently systemd does a bogus check.
If we don't have a unit file for a snapshot or transient unit we i
should check if the remote process label, has the required access
for a service with the SELinux label that systemd is running with.
Add SELINUX_SNAPSHOT_ACCESS_CHECK for non SELinux environments
---
src/core/dbus-manager.c | 2 +-
src/core/selinux-access.c | 9 +
src/core/selinux-access.h | 13 +
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 747bcfc..a60a568 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1112,7 +1112,7 @@ static DBusHandlerResult
bus_manager_message_handler(DBusConnection *connection,
dbus_bool_t cleanup;
Snapshot *s;
- SELINUX_ACCESS_CHECK(connection, message, start);
+
Re: [systemd-devel] [PATCH] selinux: fix selinux check for transient units
And I obviously attached wrong file...this is the right one, sorry
St 20. listopad 2013, 05:47:36 CET, Václav Pavlín napsal:
Út 19. listopad 2013, 15:16:47 CET, Michal Sekletar napsal:
On Tue, Nov 19, 2013 at 08:54:41AM -0500, Daniel J Walsh wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/2013 05:45 PM, Michal Sekletar wrote:
On Mon, Nov 18, 2013 at 04:19:20PM -0500, Daniel J Walsh wrote: On
11/16/2013 08:10 AM, Lennart Poettering wrote:
On Thu, 14.11.13 15:43, Daniel J Walsh (dwa...@redhat.com) wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 11/14/2013 12:50 PM, Harald Hoyer wrote:
On 11/05/2013 11:12 PM, Daniel J Walsh wrote:
On 11/05/2013 12:22 PM, Lennart Poettering wrote:
Ok lets add a check that checks for start on a service labeled
with the remote process label, then we can add rules like
allow systemd_logind_t self:service start
Or we can make it simpler and have the local end check against
the init_t process.
allow systemd_logind_t init_t:service start;
Which is probably a better solution, if we have no way of
differentiating the services.
Machineid usually runs as init_t now.
systemd-run runs as the label of the process that executes it,
Usually unconfined_t, and sysadm_t.
has any solution been found for this?
seems like one is needed for
https://bugzilla.redhat.com/show_bug.cgi?id=1008864
I guess the question I have is do you expect a patch from me? Or
are you guys working on it? I would go with the checking based on
process label.
I am hoping for a patch for this!
Thanks,
Lennart
This patch adds a new call for SELINUX_SNAPSHOT_ACCESS_CHECK,
because I
believe this error will happen when a snapshot is created. Also now
pass
in system when doing a system check, if it is doing a service
check and
does not pass in a unit file we will default the target to the
label that
systemd is running with.
Hi,
Maybe I am missing something but isn't this about transient units in
general, i.e. what about StartTransient()? What is going to change in
this case after applying this patch? tclass will be system since in
SELINUX_ACCESS_CHECK you now pass system as path and you will set
tclass in else branch to system which is afaik same as before.
In the current code, passing a unit_file of NULL (StartTransients
has a NULL
UnitFile) will indicate that it should do a system check. My patch is
intended to change this so a NULL UnitFile will indicate that
systemd should
check the access between the calling process label and the current
process
label for a service access. Where as the SELINUX_ACCESS_CHECK will
now pass
a system flag to the function to make it do a system check.
Hi Dan,
Agreed, I get the idea, but this means that
SELINUX_SNAPSHOT_ACCESS_CHECK should
be performed in StartTransient branch in dbus-manager.c too and macro
should be
probably renamed to something like SELINUX_RUNTIME_UNIT_ACCESS_CHECK.
Hope that makes sense.
Michal
Hi,
I tried to improve Dan's patch, so I added an empty call if selinux is
not supported, renamed the function so it doesn't imply it's only for
snapshots and used it in StartTransient and RemoveSnapshot as well. I
wanted to test it, but I am not sure if the policy is already updated.
Vaclav
On the side note, you forgot to define
SELINUX_SNAPSHOT_ACCESS_CHECK as
do {} while (false) in case if we don't HAVE_SELINUX.
It might be the case that I completely misunderstood what's this
about,
in such case ignore this email.
Michal
Thanks added SELINUX_SNAPSHOT_ACCESS_CHECK as do {} while (false) in
case if
we don't HAVE_SELINUX.
Updated patch.
snip
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKLbaEACgkQrlYvE4MpobPMMACeNeyrC3OBhx99DZ+JzOtV1ykZ
PvMAoJfiYBoJRBFgh2+FyOV+tNTuojNU
=9I5G
-END PGP SIGNATURE-
From b372b48016f5c015b34db9f53b7a54a64a5a84e8 Mon Sep 17 00:00:00 2001
From: Dan Walsh dwa...@redhat.com
Date: Mon, 18 Nov 2013 15:52:37 -0500
Subject: [PATCH] Fix SELinux check for snapshot and transitent unit
creation.
SELinux does not have a path to check for a snapshot or transient
unit files service creation. Currently systemd does a bogus check.
If we don't have a unit file for a snapshot or transient unit we i
should check if the remote process label, has the required access
for a service with the SELinux label that systemd is running with.
Add SELINUX_SNAPSHOT_ACCESS_CHECK for non SELinux environments
---
src/core/dbus-manager.c | 2 +-
src/core/selinux-access.c | 9 +
src/core/selinux-access.h | 13 +
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 747bcfc..a60a568 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1112,7 +1112,7 @@ static DBusHandlerResult
Re: [systemd-devel] [PATCH 1/3] systemctl: check for triggering units before calling StopUnit
Michal Sekletar píše v Čt 08. 08. 2013 v 15:19 +0200:
Rearranging the code in a way that we always check for triggers
before we issue StopUnit D-Bus call will make behavior consistent,
thus triggers are always checked.
The patch looks good, but I struggled to get through the commit message
- it might make more sense if you split it into two sentences:
Rearranging the code in a way that we always check for triggers before
we issue StopUnit D-Bus call. This will make behavior consistent,
because triggers are always checked.
https://bugzilla.redhat.com/show_bug.cgi?id=908690
---
src/systemctl/systemctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 8ec1824..ee47841 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -1980,6 +1980,16 @@ static int start_unit(DBusConnection *bus, char
**args) {
return log_oom();
}
+/* When stopping units, warn if they can still be triggered by
+ * another active unit (socket, path, timer) */
+if (!arg_quiet streq(method, StopUnit)) {
+if (one_name)
+check_triggering_units(bus, one_name);
+else
+STRV_FOREACH(name, args+1)
+check_triggering_units(bus, *name);
+}
+
if (one_name) {
ret = start_unit_one(bus, method, one_name, mode, error, s);
if (ret 0)
@@ -1998,16 +2008,6 @@ static int start_unit(DBusConnection *bus, char
**args) {
r = wait_for_jobs(bus, s);
if (r 0)
return r;
-
-/* When stopping units, warn if they can still be triggered
by
- * another active unit (socket, path, timer) */
-if (!arg_quiet streq(method, StopUnit)) {
-if (one_name)
-check_triggering_units(bus, one_name);
-else
-STRV_FOREACH(name, args+1)
-check_triggering_units(bus, *name);
-}
}
return ret;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] makefile:put macros file to the correct place
Zbigniew Jędrzejewski-Szmek píše v Čt 27. 06. 2013 v 17:00 +0200: On Thu, Jun 27, 2013 at 04:30:12PM +0200, Vaclav Pavlin wrote: From: Fedora systemd team systemd-ma...@redhat.com --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 3a196a6..c3988e8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -65,7 +65,7 @@ pkgconfigdatadir=$(datadir)/pkgconfig pkgconfiglibdir=$(libdir)/pkgconfig polkitpolicydir=$(datadir)/polkit-1/actions bashcompletiondir=@bashcompletiondir@ -rpmmacrosdir=$(sysconfdir)/rpm +rpmmacrosdir=$(prefix)/lib/rpm/macros.d Is this a recent change in rpmbuild? I don't see any macros in the new dir on FC19, and even don't have the dir on FC18... Zbyszek RPM guys removed systemd from default build-requires in buildroot by mistake. So we discussed how to do it so that systemd does not have to be default require for all packages that ship unit files. The result of this discussion was that we create a subpackage that will contain only rpm macro files. Michal Schmidt then suggested we could follow this bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=846679 and move macro file to the new location. And yes, this applies only for F19+. Vaclav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-random-seed: start random-seed service after fedora-readonly
Kay Sievers píše v Čt 14. 03. 2013 v 12:40 +0100: On Thu, Mar 14, 2013 at 9:55 AM, Vaclav Pavlin vpav...@redhat.com wrote: From: Václav Pavlín vpav...@redhat.com When using readonly-root systemd-random-seed.service fails because /var/lib/random-seed is not writable at the time. Adding fedora-readonly.service to systemd-randomd-seed's After solves this issue - mentioned file is bind mounted as rw before it is used. https://bugzilla.redhat.com/show_bug.cgi?id=888615 --- units/systemd-random-seed-load.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/units/systemd-random-seed-load.service.in b/units/systemd-random-seed-load.service.in index e9156ef..2ff78d5 100644 --- a/units/systemd-random-seed-load.service.in +++ b/units/systemd-random-seed-load.service.in @@ -10,7 +10,7 @@ Description=Load Random Seed Documentation=man:systemd-random-seed-load.service(8) man:random(4) DefaultDependencies=no RequiresMountsFor=@RANDOM_SEED@ -After=systemd-readahead-collect.service systemd-readahead-replay.service systemd-remount-fs.service +After=systemd-readahead-collect.service systemd-readahead-replay.service systemd-remount-fs.service fedora-readonly.service Before=sysinit.target final.target You can never add fedora stuff to upstream. This service would need to be _properly_ implemented, and shipped upstream too, if it should be referenced. :) Can't you add a Before= to the fedora-* service? Kay Sure, that sounds much better. I will do that this way, thanks Kay. Vaclav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Hackfest!
Colin Guthrie píše v Út 19. 02. 2013 v 12:35 +: 'Twas brillig, and David Strauss at 19/02/13 07:08 did gyre and gimble: I'd like to participate online. Will people be joining a Google+ Hangout or the #systemd IRC channel? I'm personally interested in TLS support for the gateway. I have quite a bit of x.509 experience to add for development and documentation. I'd also like to join online in some capacity, tho' have a very busy week this week at $dayjob :s Also I think my G+ Hangouts are a bit broken right now due to some cairo update :s Hi, I'm trying to get some decent webcam fo Hangout, but I cannot promise anything now:( IRC channel should by no problem, I guess. Regards Vaclav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Various bug fixes
You can find few patches for various bugs in attachement.
--
Regards
Václav Pavlín and Lukáš Nykrýn
From 55fa1c1b09933e55ce105279f2591674381c5345 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?V=C3=A1clav=20Pavl=C3=ADn?= vpav...@redhat.com
Date: Fri, 21 Sep 2012 12:04:02 +0200
Subject: [PATCH 01/18] cgtop: missing '-'
Return codes in systemd are negated and
if (r 0) if (r == ENOENT)
was never true.
---
src/cgtop/cgtop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index 3756328..9eb2d2f 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -300,7 +300,7 @@ static int refresh_one(
r = cg_enumerate_subgroups(controller, path, d);
if (r 0) {
-if (r == ENOENT)
+if (r == -ENOENT)
return 0;
return r;
--
1.7.11.4
From c8f330a8910d6d04c9c073961d3ab280a17cfd32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?V=C3=A1clav=20Pavl=C3=ADn?= vpav...@redhat.com
Date: Fri, 21 Sep 2012 12:17:23 +0200
Subject: [PATCH 02/18] udev: check malloc return in collect/collect.c
Returns from no memory checks updated with log_oom call
---
src/udev/collect/collect.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/src/udev/collect/collect.c b/src/udev/collect/collect.c
index 4162c43..47c2ddd 100644
--- a/src/udev/collect/collect.c
+++ b/src/udev/collect/collect.c
@@ -142,7 +142,7 @@ static int checkout(int fd)
buf = calloc(1,bufsize + 1);
if (!buf) {
fprintf(stderr, Out of memory.\n);
-return -1;
+return log_oom();
}
memset(buf, ' ', bufsize);
ptr = buf + len;
@@ -167,7 +167,16 @@ static int checkout(int fd)
if (debug)
fprintf(stderr, Found word %s\n, word);
him = malloc(sizeof (struct _mate));
+if (!him) {
+free(buf);
+return log_oom();
+}
him-name = strdup(word);
+if (!him-name) {
+free(buf);
+free(him);
+return log_oom();
+}
him-state = STATE_OLD;
udev_list_node_append(him-node, bunch);
word = NULL;
@@ -276,7 +285,7 @@ static int missing(int fd)
buf = malloc(bufsize);
if (!buf)
-return -1;
+return log_oom();
udev_list_node_foreach(him_node, bunch) {
struct _mate *him = node_to_mate(him_node);
@@ -291,7 +300,7 @@ static int missing(int fd)
tmpbuf = realloc(buf, bufsize);
if (!tmpbuf) {
free(buf);
-return -1;
+return log_oom();
}
buf = tmpbuf;
}
@@ -431,7 +440,17 @@ int main(int argc, char **argv)
if (debug)
fprintf(stderr, ID %s: not in database\n, argv[i]);
him = malloc(sizeof (struct _mate));
+if (!him) {
+ret = ENOMEM;
+goto out;
+}
+
him-name = malloc(strlen(argv[i]) + 1);
+if (!him-name) {
+ret = ENOMEM;
+goto out;
+}
+
strcpy(him-name, argv[i]);
him-state = STATE_NONE;
udev_list_node_append(him-node, bunch);
--
1.7.11.4
From 6497710f8a333866eb21b96816134409e69b1de4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?V=C3=A1clav=20Pavl=C3=ADn?= vpav...@redhat.com
Date: Fri, 21 Sep 2012 12:40:29 +0200
Subject: [PATCH 03/18] libudev: check return value of rename
---
src/libudev/libudev-device-private.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/libudev/libudev-device-private.c b/src/libudev/libudev-device-private.c
index 00fa3b8..489bea8 100644
--- a/src/libudev/libudev-device-private.c
+++ b/src/libudev/libudev-device-private.c
@@ -101,6 +101,7 @@ int udev_device_update_db(struct udev_device *udev_device)
char filename[UTIL_PATH_SIZE];
char filename_tmp[UTIL_PATH_SIZE];
FILE *f;
+int r;
id = udev_device_get_id_filename(udev_device);
if (id
Re: [systemd-devel] systemd hackfest on Developer Conference 2013
Hi, I've created event on Google+ for the systemd Hackfest before Developer Conference 2013. At the time it is planned for two days (Thursday and Friday - February 21. and 22.) - let me know if it is ok for you, or you want it only for one day. https://plus.google.com/events/cnklef88b85tb6tgf6ue3hn32lg Please, spread the word, share the event and, of course, attend. Vaclav Pavlin Václav Pavlín píše v Út 14. 08. 2012 v 17:32 +0200: Developer Conference 2013 takes place in Brno on February next year. We have an opportunity to organize Hackfest during/before the conference. Conference should run during the weekend (Saturday and Sunday) so the hackfest can take place these days or the days before (Wed, Thu, Fri), so conference attendees will not miss presentations. What we need to now: * approximate number of hackfest attendees * preferred days Please, let us if you are interested to join the systemd hackfest and when would you like to have it organized. ___ 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] systemd hackfest on Developer Conference 2013
Lennart Poettering píše v Út 21. 08. 2012 v 17:15 +0200: On Tue, 14.08.12 17:32, Václav Pavlín (vpav...@redhat.com) wrote: Heya, Either would be fine with me, with a slight preference of before. Ok, so I would suggest to do it before. Another question is, if we should plan it for two days (Thu, Fri) or for just one day (Fri)? I will let You and Kay decide this and then pass it to the organizers of conference. I would love this. We should have a Google+ Event for this for people to sign up. G+ Event is great idea. I will create it and send you a link as soon as I will have confirmed dates of conference (and so the hackfest). Vaclav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd hackfest on Developer Conference 2013
Developer Conference 2013 takes place in Brno on February next year. We have an opportunity to organize Hackfest during/before the conference. Conference should run during the weekend (Saturday and Sunday) so the hackfest can take place these days or the days before (Wed, Thu, Fri), so conference attendees will not miss presentations. What we need to now: * approximate number of hackfest attendees * preferred days Please, let us if you are interested to join the systemd hackfest and when would you like to have it organized. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] List all available units
Lennart Poettering píše v St 08. 08. 2012 v 18:31 +0200: On Tue, 07.08.12 16:35, Václav Pavlín (vpav...@redhat.com) wrote: I am not sure we should include the units from list-unit-files in the output of list-units, as this would increase the output quite a bit, and would be hardly helpful in many cases, and slow. I didn't really meant to include output of one list-uni* parameter to another. Those lists does not have much in common and, as You point out, merged output could be slow. So, dunno, I am not entirely sure how to expose this best. We probably should get the interface right, and agree how this would be exposed to the user, before we actually think about implementing it. Neither of the three options I currently see (extend systemctl list-units, extend systemctl list-unit-files, add a new systemctl verb) are that pretty in my eyes. I would vote for the new systemctl verb option. If we present the user with a list like this we probably should show a tree view of some kind since the unit file getty@.service might get instantiated a couple of times as getty@tty1.service and so on, and hence is in a tree-like relationship. I like the idea of the tree view, but I cannot imagine how it can help to solve autocompletion problem. If I get it right, getty@.service is template file, which cannot be manually instantiated, so it can be omitted from the output (User cannot do anything with it, right?). On the other hand, getty@tty1.service is an instance, which can be stopped, restarted etc., and it will be listed in list-units output (and then in merged output of new systemctl verb as well). Another option would be to add a notice about systemctl list-unit-files in the footer of systemctl list-units. That should already be a big imprvoement, since most people probably interrpet the current advice of using --all like this. It would be helpful, but, again, does not solve the autocompletion problem. Another option would be to add systemctl complete as hidden option for usage only by bash completion, that does the merging. This makes sense to me. It could be even something like systemctl list-autocomplete-units. Yes, storing this in a hashmap does make sense. But really, before we get hacking we should think about the UI of this. Ok, I will wait for your agreement. Václav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] List all available units
As I noted here: https://bugzilla.redhat.com/show_bug.cgi?id=790768#c12 this patch doesn't solve my issue. But I think it can be solved in either systemctl or autocomlete script. If we decide to change behaviour of systemctl, the approach, I described here, can be used. If you prefer to edit autocomplete script, it can be done with merge of sytemctl output of list-units and list-unit-files and then pipe to uniq. Vaclav Jóhann B. Guðmundsson píše v Út 07. 08. 2012 v 15:21 +: On 08/07/2012 02:35 PM, Václav Pavlín wrote: https://bugzilla.redhat.com/show_bug.cgi?id=790768 I thought Harald had already fixed this one but perhaps Lennart never committed it. See [1]. JBG 1.http://lists.freedesktop.org/archives/systemd-devel/2012-February/004573.html ___ 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] List all available units
Hi everyone, I started to work on these two bugs (if I solve the first one, the second one will be almost solved as well): https://bugzilla.redhat.com/show_bug.cgi?id=748512 https://bugzilla.redhat.com/show_bug.cgi?id=790768 My idea is to get list of loaded units, then list of unit files and then get info for units, which are in file list, but not in list of loaded units. Then I can print info for all units available in the system (whether they are loaded or not). I would extract code responsible for loading unit_infos from systemctl.c/list_units to the function (so it will be reusable) and do the same with the systemctl.c/lis_unit_files. I would like to use hashmap to store loaded units, because it will be faster, than using array, to check it against unit file list. With this it would be nice to use hashmap directly in functions list_units and output_units_list, so I don't have to move data from array to hashmap and back to array. I would like to know your opinion and/or suggestions how to solve this better. Thanks Václav Pavlín ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
