| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
answer 'no'
|
| |
|
| |
|
| |
|
|
|
|
| |
configured first.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
elogind doesn't need and thus does not support it.
|
|
|
|
| |
elogind doesn't need and thus does not support it.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
unneeded function.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
them.
|
|
|
|
| |
by strstrip()
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
They are nowhere needed.
|
| |
|
| |
|
|
|
|
| |
Doesn't hurt to leave that possibility open.
|
|
|
|
| |
elogind has no inotify test program
|
| |
|
| |
|
|
|
|
| |
They, or at least bits of them, have slithered in during migration.
|
|
|
|
|
|
|
| |
No matter how much advanced check_tree.pl is, there are plenty possibilities
where upstream changes can be transported wrong. Mainly adding something we then
have to mask out. But at the end of the day this is actually wanted, so we do
not miss important changes.
|
| |
|
| |
|
| |
|
| |
|
| |
|