Re: [systemd-devel] [PATCH] bash-completion: split completions and move to new location
2013/3/3 Kay Sievers k...@vrfy.org: On Sat, Mar 2, 2013 at 10:46 PM, Michael Biebl mbi...@gmail.com wrote: since this has been on the TODO list and Kay has poked me about this, I went ahead and made the bash completion compatible with the new scheme. I.e. move the files to /usr/share/bash-completions/completions and make them available under the binary's name. I decided to split up the large completion file instead of using symlinks. The duplication is minimal and by splitting up, the files become much more readable and we only need to actually install those bits which are enabled via --config. Nice job! Commit it. I'm happy that we leave /etc alone with that. Packages should not install any static data there these days. For now I've hard-coded bashcompletiondir=$(data)/bash-completion/completions which I think is good enough. Needs to be $(datadir), I guess. Works fine for me otherwise. Committed with this change. Thanks for catching this! Removed the item from the TODO list, too. That said, I can prep a follow-up patch, which makes that configurable and uses pkg-config --variable=completionsdir bash-completion. Pretty much what we do for --with-dbus*dir. Let me know if you also want the latter bits. Sounds good to me. Ok, will have a look then. Should be mostly CP from what is already in configure.ac. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/5] tpmfiles: add missing parenthesis
On Sat, Mar 02, 2013 at 05:56:16PM +0100, Michal Sekletar wrote:
Hi Carlos,
I shouldn't use word Agreed, because it seems that it caused some confusion.
On Mar 2, 2013, at 3:55 PM, Carlos Silva r3...@r3pek.org wrote:
On Sat, Mar 2, 2013 at 1:46 PM, Michal Sekletar sekleta...@gmail.com
wrote:
-if (!i-type == IGNORE_DIRECTORY_PATH ||
!streq(dent-d_name, p)) {
+if (!(i-type == IGNORE_DIRECTORY_PATH ||
!streq(dent-d_name, p))) {
After the change we have:
if (i-type != I_D_P streq(d_name, p))
Agreed.
This is what it will be after change, not saying that it is correct.
Shouldn't we instead have
if (i-type != I_D_P || strneq(d_name, p))
?
I don't think so, because we want to get rid of directory, when
item type is different from IGNORE_DIRECTORY_PATH or if we are
processing item of type I_D_N, but directory names does not match.
Putting this condition into code I get:
i-type != I_D_P || (i-type == I_D_N strneq(d_name, p))
which is equivalent to
i-type != I_D_P || strneq(d_name, p)
which is what I posted above.
And this is different from the proposed version.
I *assume* that original behaviour is actually correct.
The original was certainly incorrect because ! has higher precdence than
==.
Zbyszek
Thing is, you didn't kept original behaviour ;)
(!a || !b) == !(a b) != !(a || !b)
or am I missing something here? ;)
I still believe that original approach is correct.
Michal
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/5] tpmfiles: add missing parenthesis
Hi Zbigniew, you are right. I overlooked the fact that negation has higher precedence than equal operator. Thank you! Would you be so kind and commit the patch? Michal. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/2] fixes for arm and rndis tethered network
A couple fixes that I found in the process of getting rndis network device to work properly with systemd/udev. Rob Clark (2): udev: fix segfault with android rndis udev: fix for devices without PCI src/udev/udev-builtin-net_id.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) -- 1.8.1.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] udev: fix segfault with android rndis
The android gadget driver for network tethering over rndis somehow has a
parent device with a null name. Probably this is bug in android driver,
but it is easy enough to make systemd/udev behave gracefully and not
segfault. And this will help for making linux distros with systemd
(like fedora) work on android devices.
Signed-off-by: Rob Clark robdcl...@gmail.com
---
src/udev/udev-builtin-net_id.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
index fbacb45..fdbec5a 100644
--- a/src/udev/udev-builtin-net_id.c
+++ b/src/udev/udev-builtin-net_id.c
@@ -256,7 +256,7 @@ static int names_pci(struct udev_device *dev, struct
netnames *names) {
if (!parent)
return -ENOENT;
/* check if our direct parent is a PCI device with no other bus
in-between */
-if (streq(pci, udev_device_get_subsystem(parent))) {
+if (streq_ptr(pci, udev_device_get_subsystem(parent))) {
names-type = NET_PCI;
names-pcidev = parent;
} else {
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] udev: fix for devices without PCI
On many arm embedded SoC's (phones, tablets, etc), there is no PCI bus.
So it is not an error if names_pci() fails to find a parent PCI device.
Signed-off-by: Rob Clark robdcl...@gmail.com
---
src/udev/udev-builtin-net_id.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
index fdbec5a..c5d6d51 100644
--- a/src/udev/udev-builtin-net_id.c
+++ b/src/udev/udev-builtin-net_id.c
@@ -439,9 +439,7 @@ static int builtin_net_id(struct udev_device *dev, int
argc, char *argv[], bool
}
/* get PCI based path names, we compose only PCI based paths */
-err = names_pci(dev, names);
-if (err 0)
-goto out;
+names_pci(dev, names);
/* plain PCI device */
if (names.type == NET_PCI) {
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] udev: fix segfault with android rndis
On Sun, Mar 3, 2013 at 6:55 PM, Rob Clark robdcl...@gmail.com wrote: The android gadget driver for network tethering over rndis somehow has a parent device with a null name. Probably this is bug in android driver, but it is easy enough to make systemd/udev behave gracefully and not segfault. And this will help for making linux distros with systemd (like fedora) work on android devices. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] udev: fix for devices without PCI
On Sun, Mar 3, 2013 at 6:55 PM, Rob Clark robdcl...@gmail.com wrote: On many arm embedded SoC's (phones, tablets, etc), there is no PCI bus. So it is not an error if names_pci() fails to find a parent PCI device. As the comment in the code lines above states, all these names work on for PCI based setups. Other buses and architectures would need proper code to handle them, not just skip over the pci prefix. We cannot do that. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] udev: fix for devices without PCI
On Sun, Mar 3, 2013 at 1:06 PM, Kay Sievers k...@vrfy.org wrote: On Sun, Mar 3, 2013 at 6:55 PM, Rob Clark robdcl...@gmail.com wrote: On many arm embedded SoC's (phones, tablets, etc), there is no PCI bus. So it is not an error if names_pci() fails to find a parent PCI device. As the comment in the code lines above states, all these names work on for PCI based setups. Other buses and architectures would need proper code to handle them, not just skip over the pci prefix. We cannot do that. Of course, if you have a better idea in mind, I am all-ears. I'm not a systemd/udev expert, so certainly don't claim that it is the best fix. It would be nice for this to work somehow properly on the various PCI-less systems out there. BR, -R Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] udev: fix for devices without PCI
On Sun, Mar 3, 2013 at 7:10 PM, Rob Clark robdcl...@gmail.com wrote: On Sun, Mar 3, 2013 at 1:06 PM, Kay Sievers k...@vrfy.org wrote: On Sun, Mar 3, 2013 at 6:55 PM, Rob Clark robdcl...@gmail.com wrote: On many arm embedded SoC's (phones, tablets, etc), there is no PCI bus. So it is not an error if names_pci() fails to find a parent PCI device. As the comment in the code lines above states, all these names work on for PCI based setups. Other buses and architectures would need proper code to handle them, not just skip over the pci prefix. We cannot do that. Of course, if you have a better idea in mind, I am all-ears. I'm not a systemd/udev expert, so certainly don't claim that it is the best fix. It would be nice for this to work somehow properly on the various PCI-less systems out there. It depends on the bus type used for the parent device(s), we would need to compose a stable and predictable name from the properties of the parent device(s). In most cases it's probably a simple platform bus hack, which we will see. What does: ls -l /sys/class/net print on these systems? There are only a few chars left to use for network names, so just using the platform name would probably not work in some cases. Not sure if someone has an idea, what to do here ... Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] udev: fix for devices without PCI
On Sun, Mar 3, 2013 at 1:22 PM, Kay Sievers k...@vrfy.org wrote: On Sun, Mar 3, 2013 at 7:10 PM, Rob Clark robdcl...@gmail.com wrote: On Sun, Mar 3, 2013 at 1:06 PM, Kay Sievers k...@vrfy.org wrote: On Sun, Mar 3, 2013 at 6:55 PM, Rob Clark robdcl...@gmail.com wrote: On many arm embedded SoC's (phones, tablets, etc), there is no PCI bus. So it is not an error if names_pci() fails to find a parent PCI device. As the comment in the code lines above states, all these names work on for PCI based setups. Other buses and architectures would need proper code to handle them, not just skip over the pci prefix. We cannot do that. Of course, if you have a better idea in mind, I am all-ears. I'm not a systemd/udev expert, so certainly don't claim that it is the best fix. It would be nice for this to work somehow properly on the various PCI-less systems out there. It depends on the bus type used for the parent device(s), we would need to compose a stable and predictable name from the properties of the parent device(s). In most cases it's probably a simple platform bus hack, which we will see. What does: ls -l /sys/class/net print on these systems? yeah, it is a platform device... devices/platform/msm_hsusb/gadget/net/rndis0: [robclark@touchpad:~]$ ls -l /sys/class/net total 0 lrwxrwxrwx 1 root root 0 Mar 3 13:16 dummy0 - ../../devices/virtual/net/dummy0 lrwxrwxrwx 1 root root 0 Mar 3 13:16 lo - ../../devices/virtual/net/lo lrwxrwxrwx 1 root root 0 Mar 3 13:16 rmnet0 - ../../devices/virtual/net/rmnet0 lrwxrwxrwx 1 root root 0 Mar 3 13:16 rmnet1 - ../../devices/virtual/net/rmnet1 lrwxrwxrwx 1 root root 0 Mar 3 13:16 rmnet2 - ../../devices/virtual/net/rmnet2 lrwxrwxrwx 1 root root 0 Mar 3 13:16 rmnet3 - ../../devices/virtual/net/rmnet3 lrwxrwxrwx 1 root root 0 Mar 3 13:16 rmnet4 - ../../devices/virtual/net/rmnet4 lrwxrwxrwx 1 root root 0 Mar 3 13:16 rmnet5 - ../../devices/virtual/net/rmnet5 lrwxrwxrwx 1 root root 0 Mar 3 13:16 rmnet6 - ../../devices/virtual/net/rmnet6 lrwxrwxrwx 1 root root 0 Mar 3 13:16 rmnet7 - ../../devices/virtual/net/rmnet7 lrwxrwxrwx 1 root root 0 Mar 3 13:17 rndis0 - ../../devices/platform/msm_hsusb/gadget/net/rndis0 lrwxrwxrwx 1 root root 0 Mar 3 13:16 sit0 - ../../devices/virtual/net/sit0 There are only a few chars left to use for network names, so just using the platform name would probably not work in some cases. Not sure if someone has an idea, what to do here ... Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bash-completion: split completions and move to new location
2013/3/3 Michael Biebl mbi...@gmail.com:
2013/3/3 Kay Sievers k...@vrfy.org:
On Sat, Mar 2, 2013 at 10:46 PM, Michael Biebl mbi...@gmail.com wrote:
That said, I can prep a follow-up patch, which makes that configurable
and uses pkg-config --variable=completionsdir bash-completion.
Pretty much
what we do for --with-dbus*dir.
Let me know if you also want the latter bits.
Sounds good to me.
Ok, will have a look then. Should be mostly CP from what is already
in configure.ac.
See attached patches.
First one replaced pkg-config with $PKG_CONFIG (which we also
recommend in man 7 daemon).
The second makes bashcompletiondir configurable via
--with-bashcompletiondir=DIR.
If not specified, it will try $PKG_CONFIG --variable=completionsdir
bash-completion.
Since we don't want a hard build dependency on bash-completion, it
will fall-back to ${datadir}/bash-completion/completions if
bash-completion.pc is not installed.
Ok to commit?
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
0001-build-sys-use-PKG_CONFIG-instead-of-calling-the-pkg-.patch
Description: Binary data
0002-build-sys-don-t-hard-code-bash-completion-directory.patch
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] On(Resume|suspend|hibernate) in unit files?
On 1 March 2013 07:24, Cristian Rodríguez crrodrig...@opensuse.org wrote: Having this confessed non-ideal ReloadOnResume ,StopOnSuspend in unit files etc will make extremely easy to avoid relying on either pm-utils hooks or those new in /usr/lib/systemd/systemd-sleep and having to patch buggy software, most likely by introducing more dependencies and more bugs into already roting legacy pieces of code. Would not Conflicts=sleep.target do what you want? (I tried to test it out but suspend is broken on my system at the moment... :/) This would only cover systemd/systemctl initiated PM transitions AFAICT though - ie. something manually echoing mem into /sys/power/state would be missed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bash-completion: split completions and move to new location
On Mon, Mar 4, 2013 at 12:18 AM, Michael Biebl mbi...@gmail.com wrote:
2013/3/3 Michael Biebl mbi...@gmail.com:
2013/3/3 Kay Sievers k...@vrfy.org:
On Sat, Mar 2, 2013 at 10:46 PM, Michael Biebl mbi...@gmail.com wrote:
That said, I can prep a follow-up patch, which makes that configurable
and uses pkg-config --variable=completionsdir bash-completion.
Pretty much
what we do for --with-dbus*dir.
Let me know if you also want the latter bits.
Sounds good to me.
Ok, will have a look then. Should be mostly CP from what is already
in configure.ac.
See attached patches.
First one replaced pkg-config with $PKG_CONFIG (which we also
recommend in man 7 daemon).
The second makes bashcompletiondir configurable via
--with-bashcompletiondir=DIR.
If not specified, it will try $PKG_CONFIG --variable=completionsdir
bash-completion.
Since we don't want a hard build dependency on bash-completion, it
will fall-back to ${datadir}/bash-completion/completions if
bash-completion.pc is not installed.
Ok to commit?
Sure. Works fine here.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/5] tpmfiles: add missing parenthesis
On Sun, Mar 03, 2013 at 05:10:46PM +0100, Michal Sekletar wrote: Hi Zbigniew, you are right. I overlooked the fact that negation has higher precedence than equal operator. Thank you! Would you be so kind and commit the patch? Applied now. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] python - reading the journal
I don't want this work to get buried. Where are we on the revisions
suggested by Zbyszek?
On Sat, Feb 23, 2013 at 7:34 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Sat, Feb 23, 2013 at 02:05:27PM +, Steven Hiscocks wrote:
On 23/02/13 00:43, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Feb 21, 2013 at 06:46:35PM +, Steven Hiscocks wrote:
On 21/02/13 01:49, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Feb 19, 2013 at 09:02:56PM +, Steven Hiscocks wrote:
I've pushed a few more commits.
I've pushed a few commits to
https://github.com/keszybz/systemd/commits/python-systemd-reader
This is your tree but rebased onto my id128 stuff, and modified
to use it. It also has sphinx-generated documentation and gcc
all warnings fixed. Please have a look.
Zbyszek
Thanks Zbyszek. Looks really good. Tidied it up a bit :)
With the macros for python 2 and 3 differences:
I wonder if unicode_FromString is a bit confusing, as the macro
returns a string and not Unicode for python2? Same for long_AsLong,
which returns int in python2?
I don't think that this matters too much. There's a comment about
the naming convention before the macros, and anyway this is purely
internal stuff.
Also, not related to the commits:
I've noted that `sd_journal_get_cursor` man pages states that it
returns 0 on success, but it actually returns 1. Note sure if the
code or man page is in error. There is a comment in _reader.c
get_next against `sd_journal_get_cursor`, which I guess needs to be
removed once this is clarified.
This has been now fixed in the master branch.
Good stuff :)
I've pushed a few more commits to
https://github.com/keszybz/systemd/commits/python-systemd-reader.
Important changes:
1. Checks for return values of all function calls, so now
everything should fail nicely, even on OOM conditions. This
lengthens the code quite a bit, but seems unavoidable.
2. The value returned for __TIMESTAMP_MONOTONIC:
both fields are returned as a tuple. Under Python 3
a named tuple is used:
from systemd import journal
t = journal.Journal().get_next()
t['__MONOTONIC_TIMESTAMP'].timestamp
datetime.timedelta(0, 15, 368483)
t['__MONOTONIC_TIMESTAMP'].bootid
UUID('9838676e-2666-4a83-b8be-b0654747f8be')
I think that this is relatively lightweight, yet nice to use.
Under Python 2.7, a normal tuple is returned, so it is necessary
to use t['__MONOTONIC_TIMESTAMP'][0], t['__MONOTONIC_TIMESTAMP'][1].
I first tried with a class, and it felt too complicated.
Like it. Makes sense as the monotonic timestamp is useless without a bootid.
Right. And we need to export everything that the journal provides.
I was thinking another way which would allow use of named tuple in
both python2.6+ and python3, would be combining the
__MONOTONIC_TIMESTAMP and _BOOT_ID together within the
`_convert_entry` method within journal.py. I assume that the boot
id returned by sd_journal_get_monotonic_usec will always be the
same as _BOOT_ID?
Actually both the time and _BOOT_ID are different, since they
are both converted (int + bytes to datetime.timedelta + uuid.UUID).
Or equally you could pass back a plain tuple for
__MONOTONIC_TIMESTAMP and then change namedtuple within python
_convert_entry?
Hm, that would be possible. Or maybe just use the named tuple
just when the C PyStructSequnce is not available. I think that
(like in most of systemd) we should concentrate on the latest
version (Python 3.3 and 3.4), with fallbacks for legacy which
don't have to be as nice.
How about changing the `seek_monotonic` method in journal.py to
accept a tuple?
I think that doesn't gain anything, but makes manual calls
minimally harder. With a tuple one can always say
.seek_monotonic(*timestamp_with_boot_id)
which is nice and explicit.
3. Sphinx documentation can be generated with 'make destdir-sphinx'.
This target is part of 'make doc-sync', which means that the documents
will be uploaded along with the man pages to freedesktop.org.
So when this is merged
http://www.freedesktop.org/software/systemd/man/python-systemd
will be the URL with docs. Preview is at:
http://keszybz.github.com/systemd/python-systemd/
This way that the docs are generated is not very nice (whole package
is installed using random DESTDIR, and sphinx-build is run with
PYTHONPATH and LD_LIBRARY_PATH pointing to this directory), but seems
to work. The documentation is only generated on request, i.e. only by
conscious developers, so it's not catastrophic even if this doesn't
always work.
I think that this is becoming mergeable.
Zbyszek
Thanks for all your work on this Zbyszek :)
:)
Zbyszek
--
David Strauss
| da...@davidstrauss.net
| +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] DBus service name encoding
I can't find any documentation on how service names get encoded for DBus. It looks pretty close to URL encoding with underscores instead of percent signs. If I can get a definitive answer, I'll update the wiki. If I can't, I can, of course, dive into the source. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] python - reading the journal
On Sun, Mar 03, 2013 at 07:10:45PM -0800, David Strauss wrote: On Sun, Mar 3, 2013 at 6:59 PM, David Strauss da...@davidstrauss.net wrote: I don't want this work to get buried. Where are we on the revisions suggested by Zbyszek? Hi David, just to wrap this up, I think that the only outstanding proposed change was something suggested by Steven: adding a NamedTuple for Python 2 for the monotonic timestamp stuff. It's more of a cosmetic/consistency thing, and I didn't touch it. Never mind. Looks like it landed in master. Yeah, and there's a bugfix from Lukas already on top :) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
