Hi folks,
Forgive me in advance if the underlying reasonings behind these
questions are a bit naive...
Will kdbus make use of polkit? If partially so, will it be feasible to
have a normal desktop system with systemd+kdbus that does not require
polkit? Will polkit play a smaller role going forward
Hi folks,
Forgive me in advance if the underlying reasonings behind these
questions are a bit naive...
Will kdbus make use of polkit? If partially so, will it be feasible to
have a normal desktop system with systemd+kdbus that does not require
polkit? Will polkit play a smaller role going forward
Hi folks,
I hope this is the right list to ask about udev. I've got a lenovo usb
keyboard with a trackpoint on it -- essentially an external replica of
the classic thinkpad keyboard. The trackpoint by default isn't very
sensitive, so I've got a udev rule that applies the settings I like:
zx2c4@th
I use konsole. It has a nice feature that when the scrollbars have been
disabled -- like in the case of a full-console app like vim or less --
it makes the mouse wheel send up and down key strokes, so that
scrolling happens. It's really nice. I open up less, and then I can
scroll through it using t
On Tue, Feb 11, 2014 at 7:09 AM, Andrey Borzenkov wrote:
> Should not it simply respect existing LESS value? Or, for that matter,
> SYSTEMD_LESS if someone thinks of a good reason to have different
> settings?
Yes, one way would be to look at LESS from the environment, and prefer
this to the inte
Hey folks,
I'm using better-initramfs [1], a very small and minimal initrd that
has been working very well for me. In switching to systemd, I found it
necessary to have the initrd mount "/run" as tmpfs, according to the
specs [2]. I made a little patch for better-initramfs, and now I'm
talking to
On Tue, Feb 11, 2014 at 5:01 PM, Dave Reisner wrote:
> systemd is already capable of setting up /run on its own:
>
> http://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount-setup.c#n69
You appear to be right.
In that case should the spec [1] be amended to remove this requirement?
[1] ht
On Tue, Feb 11, 2014 at 5:01 PM, Dave Reisner wrote:
> Strange name. I can't find one thing which I find "better" about this
> project compared to the more well-known initramfs creation tools.
I'd appreciate it if you kept the antagonism to a minimum. It adds
nothing to the technical discussion.
On Tue, Feb 11, 2014 at 5:15 PM, Dave Reisner wrote:
> I don't think there's any change needed here. The interface states:
>
> "The initrd should mount /run as a tmpfs".
> And sure enough, this isn't a requirement, but there's many valid
> reasons to do this.
Ahh, okay. I suppose what I'm won
On Tue, Feb 11, 2014 at 5:25 PM, Lennart Poettering
wrote:
> An initrd without /run is mostly pointless, no? Either you have storage
> daemons and hence need /run around, or you don't have storage daemons,
> in which case you can just boot without involving any initrd?
In my use of an initrd, I j
On Tue, Feb 11, 2014 at 6:25 PM, Colin Guthrie wrote:
> As has been mentioned elsewhere on this thread, there are a number of
> "gotchas" and corner cases, that this mechanism solved, even in the
> cases of things "working".
In my case, I'm just using devtmpfs and cryptsetup, and then switching
i
> On Tue, Feb 11, 2014 at 5:25 PM, Lennart Poettering
> wrote:
> Hmm, so how do you wait for the LUKS device to show up? You need
> something like udev around, which uses /run...
> And AFAIR the DM userspace does keep some runtime state around, and that
> one probably wants to pass over to the ho
On Tue, Feb 11, 2014 at 7:56 PM, Lennart Poettering
wrote:
> devtmpfs does not give you notifications when devices appear. If you
> want to generically wait for the right LUKS device to show up, you need
> something like udev in the mix, which provides you with notifications
> for this...
My driv
On Tue, Feb 11, 2014 at 6:40 PM, Lennart Poettering
wrote:
>
> I think adding support for $SYSTEMD_LESS which is copied to $LESS right
> before invoking less would be a good choice, since it would allow people
> to override whatever systemd tries to set.
So something along the lines of:
user_les
This allows customization of the arguments used by less. The main
motivation is that some folks might not like having --no-init on every
invocation of less.
---
If you'd like me to update some documentation, let me know what
files I should edit, and I'll send a v2.
src/shared/pager.c | 17 +++
This allows customization of the arguments used by less. The main
motivation is that some folks might not like having --no-init on every
invocation of less.
---
man/journalctl.xml | 4
man/localectl.xml | 4
man/loginctl.xml| 4
man/machinectl.xml | 4 +++
This matches the API of previous headers, such as sd-journal.h.
---
TODO | 2 --
src/libsystemd/sd-bus/bus-util.c | 8
src/libsystemd/sd-bus/sd-bus.c | 4 ++--
src/machine/machinectl.c | 2 +-
src/systemd/sd-bus.h | 4 ++--
5 files changed
---
kdbus.txt | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/kdbus.txt b/kdbus.txt
index a3d806b..de36672 100644
--- a/kdbus.txt
+++ b/kdbus.txt
@@ -6,7 +6,7 @@ all communication between processes take place over special
character device
no
Ever since the seccomp trick, this is no longer an issue.
---
README | 7 ---
1 file changed, 7 deletions(-)
diff --git a/README b/README
index b918132..df04cc9 100644
--- a/README
+++ b/README
@@ -83,13 +83,6 @@ REQUIREMENTS:
CONFIG_EFI_VARS
CONFIG_EFI_PARTITION
-
Ret values come second.
---
src/libsystemd/sd-rtnl/rtnl-util.c | 4 ++--
src/libsystemd/sd-rtnl/sd-rtnl.c | 4 ++--
src/libsystemd/sd-rtnl/test-rtnl.c | 8
src/nspawn/nspawn.c| 6 +++---
src/systemd/sd-rtnl.h | 4 ++--
5 files changed, 13 insertions(+), 13 d
Hey guys,
Thought I'd put this discussion upstream. At the moment at Gentoo [1],
we're considering building without the compat-libs, but still with
installing the pkg-config files, so that most out of date packages will
work with a rebuild without having to patch the build system, and we won't
hav
Hey guys,
This commit caught me by surprise:
http://git.zx2c4.com/systemd/commit/?id=daeb71a36a98834664e4d95773a3629b746f4db8
It wasn't in the NEWS or the mailing list post for 209, so when
updating I encountered a bit of unexpected behavior. I see that I can
disable persistent names using ne
Hi folks,
systemd-networkd seems to get started by default in 209. Why is this?
What if I don't want to use it to manage my networks? Why does it have
to be on by default?
Jason
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://l
systemd-network.service should not be started unless the administrator
runs "systemctl enable systemd-network.service", as it's entirely
unessential and most distributions use their own network management
daemons instead. If some distributions or users choose to use systemd's
built in networking, t
On Fri, Feb 21, 2014 at 2:08 PM, Tom Gundersen wrote:
> I'll just apply this patch and
> add the /etc symlink in a follow-up.
I appreciate merging my patch, so now administrators can disable it in
a sane way (without having to use mask). But still, why enable it by
default? I thought the idea of
---
configure.ac | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure.ac b/configure.ac
index 80c1449..8943c96 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1150,6 +1150,7 @@ AC_MSG_RESULT([
hostnamed: ${have_hostnamed}
timedated: ${have_ti
This reverts commit ca1a3847695d02ebe62007d8f335f23d3fe04638.
It's not right to install this by default. networkd is extremely new,
has no real world miles, and most importantly, simply
does-not-do-anything-at-all unless you write configuration files for it.
So, for folks who want to use networkd,
On Fri, Feb 21, 2014 at 4:19 PM, Lennart Poettering
wrote:
>
> Well, ultimately it's up the distributions to decide what they want to
> enable and what not.
True, but this requires manual patching and fixing up of `make
install`, which is a bummer.
> I think networkd is a good choice, especially
It doesn't make any sense to symlink this unit file into /etc when the
unit file itself isn't even installed, with --disable-networkd. This
moves the GENERAL_ALIASES logic into the right "if" block.
---
Makefile.am | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Makefile.am
On Fri, Feb 21, 2014 at 5:03 PM, Tom Gundersen wrote:
> We'd have to look in all the possible folders, and there may (and due
> to 99-deafult.link, always will) be files there, so we don't really
> have a reasonable test. When we start shipping some default .network
> files it becomes even harder
To clarify things:
1. Arch's script deals with 80-net-setup-link.rules
2. freedesktop.org wiki followed suit and added that suggestion
3. Others have said elsewhere that the proper way to do this is
actually to override 99-default.link instead.
4. Gentoo went with number 3.
Now:
5. Can numbers 1
On Fri, Feb 21, 2014 at 5:11 PM, Tom Gundersen wrote:
>
> In the not-too-distant future we'll start shipping some configuration
> files (as Lennart mentioned to do with nspawn). These are files that
> in most cases will not apply, and shouldn't interfere with your
> existing networking solutions,
On Fri, Feb 21, 2014 at 5:13 PM, Tom Gundersen wrote:
> You probably sent this before reading my previous answer, so sorry for
> repeating myself: there will soon be cases where (special purpose)
> config files are shipped by packages rather than written by
> administrators, which is what we want
Hey folks,
Just came across this section in the systemd-sleep.conf man page:
"More than one value can be specified by separating multiple values
with commas."
But then I remember seeing in 99-default.link the line,
"NamePolicy=database onboard slot path".
It seems like our configuration syntax
FYI to others experiencing weirdness, the Version api function changed
between 208 and 209:
in 208:
zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1
/org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version
systemd 208
in 209 and 210:
zx2c4@thinkpad ~ $ sudo qdbus --syst
Upstream KDE patch is here:
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/7584a63924620bac3bd87277c11cdb8cdb5018b1/diff/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp?format=diff
___
systemd-devel mailing list
sys
I'd like to have a rule that does this:
zx2c4@thinkpad /etc/udev/rules.d $ cat 90-hotkeys.rules
DRIVER=="thinkpad_acpi", ATTR{hotkey_mask}=ATTR{hotkey_recommended_mask}
Unfortunately, it "doesn't work."
This works:
zx2c4@thinkpad /etc/udev/rules.d $ cat 90-hotkeys.rules
DRIVER=="thinkpad_acpi",
Perfect, thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Tue, Jun 2, 2015 at 1:06 PM, David Herrmann wrote:
> Regarding the final github address: David Strauss kindly offered the
> 'systemd' user to us. Hence, we hope to move the repository to
> github.com/systemd/systemd this week. Sorry for the confusion, I hope
> we can settle all this this week.
Hey Lennart & Folks,
I've been watching the commits come in for timesyncd. I saw recently you're
restoring the time from file timestamps, just so something is decently
recent. Neat.
I thought I'd share a problem I had with another init system with regards
to NTP and DNSSEC, so that it's somewhere
Hi Wol,
On Fri, Apr 8, 2022 at 12:02 AM Wol wrote:
>
> On 07/04/2022 17:47, Mike Gilbert wrote:
> >> So, my guess would be that the people who dislike merged-/usr are also
> >> the ones who dislike systemd, no? i.e. do they really matter if we are
> >> talking about what to support in systemd? Th
Hey,
I've been working on my small seedrng utility, which is more or less
the same thing as systemd-random-seed.service, with a few unimportant
design differences here and there. As I'd worked with
systemd-random-seed.service quite a bit before, its choices comprised
much of my mental model starti
Hey Lennart,
On Mon, May 2, 2022 at 11:19 AM Lennart Poettering
wrote:
> I think /var/cache/ is not the right place, because of the weak
> persistency guarantees on it. i.e. /var/cache/ much like /var/tmp/
> means "hey, please keep this, but it's OK if you don't". I think
> that's too little thou
43 matches
Mail list logo
