Re: [systemd-devel] [PATCH] build-sys: merge libsystemd-login into libsystemd
On Fri, Jan 17, 2014 at 4:07 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
--- a/src/libsystemd/libsystemd.sym
+++ b/src/libsystemd/libsystemd.sym
@@ -7,8 +7,91 @@
(at your option) any later version.
***/
+/* Original symbols from systemd v31 */
+
+LIBSYSTEMD_LOGIN_31 {
Do I get this right? This exports the exact same symbols from the new lib?
This does not sound right. We should not try to be too smart here.
Symbol versions are supposed to avoid exactly the problem this will
create. The old symbols should not be provided by the new lib, to
allow the loading of the old and new lib into the same process without
clashes. We have no control which library is linked in over other
dependencies, it's very easy to end up with both libs in one process,
just by linking a third unrelated lib.
If backwards-compat is needed, it should be provided by a compat
package shipping the old lib, and not by double-exporting symbols from
the old and the new lib at the same time.
All this is nothing else in behavior than a SONAME bump, which is a
very common task for distros to solve. Actually it's exactly what a
distro is for, to solve these sorts of problems. Upstream packages
should not try to do magic things here, it just makes things too
fragile in the end.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] providing backwards compatibility
On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
So there's binary compatibility, and source compatibility.
It would be nice if we could do those changes without
a) requiring recompilation (binary)
b) requiring editing build scripts in dependent packages (source).
For b, keeping around a .pc file which points to the *new* library
name should be enough:
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
No, it will clash with the files from the old lib package. We should
not do that, if we no longer provide the same lib.
For a, a compatibility symlink (e.g. libsystemd-login.so.0 - libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
Same here, it creates clashes with the old files and is not strictly
what it pretends to be with the symlink name.
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)
Yes, I think that's the way to go.
This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?
What are we trying to solve here? This is the job of the distro, it is
what it is there for. The distro either leaves the old lib around as
long as needed, or it re-compiles the users to use the new one.
Please do not mix code (upstream) and system composition
(distribution) too much here. It's all really the same model as an
SONAME bump, something that happens every day.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
We're running into this too with lots of automount units. They log a fair bit as they start, and that overwhelms the journal buffer before it starts. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] providing backwards compatibility
Hi,
As far as I understand things, the goal is to be API compatible in terms
of function calls, but change the name of the pc files which is an API
break. Is this a correct summary? (if not then some of my comments below
don't work :D)
'Twas brillig, and Kay Sievers at 17/01/14 08:18 did gyre and gimble:
On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
So there's binary compatibility, and source compatibility.
It would be nice if we could do those changes without
a) requiring recompilation (binary)
b) requiring editing build scripts in dependent packages (source).
For b, keeping around a .pc file which points to the *new* library
name should be enough:
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
No, it will clash with the files from the old lib package. We should
not do that, if we no longer provide the same lib.
I guess Fedora do things differently, but we ship pc files in the -devel
package, so there would be no clashes with the old lib package for us...
This would be very useful.
For a, a compatibility symlink (e.g. libsystemd-login.so.0 -
libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
Same here, it creates clashes with the old files and is not strictly
what it pretends to be with the symlink name.
If said symlink is binary compatible, you could just ship an updated
version of that package. Sure it's a bit of a lie in that it's not a
real lib but I'd be OK with that personally (esp as it has to be done by
hand). If not then a stub lib rather than symlink wouldn't be lying so
is still OK as a plan if compatibility is desirable.
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)
Yes, I think that's the way to go.
This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?
What are we trying to solve here? This is the job of the distro, it is
what it is there for. The distro either leaves the old lib around as
long as needed, or it re-compiles the users to use the new one.
Please do not mix code (upstream) and system composition
(distribution) too much here. It's all really the same model as an
SONAME bump, something that happens every day.
Well you're also forcing code work onto system composition people as
they actively need patch things when we could provide an easy mechanism
for them to avoid this. This is different to an SONAME bump which
generally doesn't change the name of the .pc file and will often be fine
with a rebuild without any code modification.
As a disro maintainer, I'd be happy enough to ship a new systemd then
rebuild needed packages accordingly. What I'd be less happy about is the
API change that means my configure scripts don't work any longer and I
have to push patches into the consumer packages. There is no real need
for compat libs here, just compat .pc files. So from a distro
perspective I'd be happy with just that.
Perhaps you'd argue that such compat .pc files should just be shipped in
the distro's systemd package and not upstream? What I'm a little
confused about is that RHEL is going to be shipping systemd 207 or 208
and these old .pc names will be kinda embedded for quite some time.
Therefore consumer upstreams will be under pressure to keep the old
names in their configure scripts for a good number of years. If we
change them then we're forcing them to do an if/else structure in their
configures to check for both which is a little nasty. Surely shipping
compat .pc files just makes life easier for all concerned until there is
the need for a real API break?
Forgive me if I've misunderstood some other details of the change.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: merge libsystemd-login into libsystemd
On Fri, Jan 17, 2014 at 9:02 AM, Kay Sievers k...@vrfy.org wrote:
On Fri, Jan 17, 2014 at 4:07 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
--- a/src/libsystemd/libsystemd.sym
+++ b/src/libsystemd/libsystemd.sym
@@ -7,8 +7,91 @@
(at your option) any later version.
***/
+/* Original symbols from systemd v31 */
+
+LIBSYSTEMD_LOGIN_31 {
Do I get this right? This exports the exact same symbols from the new lib?
This does not sound right. We should not try to be too smart here.
Symbol versions are supposed to avoid exactly the problem this will
create. The old symbols should not be provided by the new lib, to
allow the loading of the old and new lib into the same process without
clashes. We have no control which library is linked in over other
dependencies, it's very easy to end up with both libs in one process,
just by linking a third unrelated lib.
If backwards-compat is needed, it should be provided by a compat
package shipping the old lib, and not by double-exporting symbols from
the old and the new lib at the same time.
All this is nothing else in behavior than a SONAME bump, which is a
very common task for distros to solve. Actually it's exactly what a
distro is for, to solve these sorts of problems. Upstream packages
should not try to do magic things here, it just makes things too
fragile in the end.
What might work out instead is adding all the symbols of the libs we
want to merge to libsystemd.so, with its _correct_ symbol version
prefix LIBSYSTEMD_209, leave the original libs untouched and
standalone, not even try to do any stub wrapping.
Distros then should change the current users to the new lib and
recompile. After that, with the next release, we will remove the old
libs and have only libsystemd.so and the new names in the systemd
sources.
After that point, distros can still provide the old lib packages as
long as needed, if they care, but upstream defaults would be without
any weird magic or SONAME or file name clashes.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] providing backwards compatibility
On Fri, Jan 17, 2014 at 10:28 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
As far as I understand things, the goal is to be API compatible in terms
of function calls, but change the name of the pc files which is an API
break. Is this a correct summary? (if not then some of my comments below
don't work :D)
'Twas brillig, and Kay Sievers at 17/01/14 08:18 did gyre and gimble:
On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
So there's binary compatibility, and source compatibility.
It would be nice if we could do those changes without
a) requiring recompilation (binary)
b) requiring editing build scripts in dependent packages (source).
For b, keeping around a .pc file which points to the *new* library
name should be enough:
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
No, it will clash with the files from the old lib package. We should
not do that, if we no longer provide the same lib.
I guess Fedora do things differently, but we ship pc files in the -devel
package, so there would be no clashes with the old lib package for us...
This would be very useful.
The header will not change, the new lib will install them too. So your
old -devel package cannot be installed in parallel.
For a, a compatibility symlink (e.g. libsystemd-login.so.0 -
libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
Same here, it creates clashes with the old files and is not strictly
what it pretends to be with the symlink name.
If said symlink is binary compatible, you could just ship an updated
version of that package. Sure it's a bit of a lie in that it's not a
real lib but I'd be OK with that personally (esp as it has to be done by
hand). If not then a stub lib rather than symlink wouldn't be lying so
is still OK as a plan if compatibility is desirable.
No, it's not ok to rely on such magic. The SONAME is not the same, and
such hacks do not belong there.
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)
Yes, I think that's the way to go.
This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?
What are we trying to solve here? This is the job of the distro, it is
what it is there for. The distro either leaves the old lib around as
long as needed, or it re-compiles the users to use the new one.
Please do not mix code (upstream) and system composition
(distribution) too much here. It's all really the same model as an
SONAME bump, something that happens every day.
Well you're also forcing code work onto system composition people as
they actively need patch things when we could provide an easy mechanism
for them to avoid this. This is different to an SONAME bump which
generally doesn't change the name of the .pc file and will often be fine
with a rebuild without any code modification.
As a disro maintainer, I'd be happy enough to ship a new systemd then
rebuild needed packages accordingly. What I'd be less happy about is the
API change that means my configure scripts don't work any longer and I
have to push patches into the consumer packages. There is no real need
for compat libs here, just compat .pc files. So from a distro
perspective I'd be happy with just that.
It's just one echo and you have that file if you need it.
Perhaps you'd argue that such compat .pc files should just be shipped in
the distro's systemd package and not upstream? What I'm a little
confused about is that RHEL is going to be shipping systemd 207 or 208
and these old .pc names will be kinda embedded for quite some time.
Therefore consumer upstreams will be under pressure to keep the old
names in their configure scripts for a good number of years. If we
change them then we're forcing them to do an if/else structure in their
configures to check for both which is a little nasty. Surely shipping
compat .pc files just makes life easier for all concerned until there is
the need for a real API break?
Forgive me if I've misunderstood some other details of the change.
We should just keep the libs as they are for a release, but provide
the functionality in the new lib under its correct name, and post
stuff over. After that's done we should see what's actually left to
cover, I
Re: [systemd-devel] [PATCH v2 6/8] add GOP mode setting and splash drawing support
Hi Tom, On Thu, Jan 16, 2014 at 5:21 PM, Tom Gundersen t...@jklm.no wrote: Hi Joonas, On Thu, Jan 16, 2014 at 4:13 PM, Joonas Lahtinen joonas.lahti...@linux.intel.com wrote: By our measurements, the original BGRX code only adds some 5 milliseconds to the boot time compared to no logo at all, where the BMP code adds almost 70 milliseconds. I think the most difference comes from the fact that in the BGRX file the pixel data is already in format suitable format for UEFI blit operations, and pixels are pushed to the blit operation as a big batch, just like they are loaded as one big batch. The BMP code invidually loops each pixel. Would the BGRX format be accepted aside the BMP format, for these speed reasons? Could we first try to optimize the BMP loader? Also, could you share your test image so I can have a look? We've simply used the web page logo [1] exported using Gimp: $ identify gummiboot-icon3.bmp gummiboot-icon3.bmp BMP 295x245 295x245+0+0 8-bit DirectClass 218KB 0.000u 0:00.000 [1] http://freedesktop.org/wiki/Software/gummiboot/gummiboot-icon.png -- Mikko ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Add keyboard leds helper app
Hey Lennart :), On vie, 2014-01-17 at 12:04 +0100, Lennart Poettering wrote: On Fri, 17.01.14 12:01, Carlos Garnacho (carl...@gnome.org) wrote: This helper program checks the leds available on keyboard devices and exports these as list of keywords in the ID_INPUT_KEYBOARD_LEDS property. The new .rule ensures this helper program runs at the time any keyboard is detected/plugged. What's the usecase for this? Complementing this code, I've got a gnome-settings-daemon patch to show an OSD to hint about *Lock keys being pressed when the keyboard in question does not have leds to tell so. The laptop I got recently has none, and it buggers me when I start yelling without noticing. (And this feels like it should be part of the input_id builtin) Oh, will check there. I first looked at the keyboard builtin before going for the standalone program, although this felt quite out of place there. Cheers, Carlos ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Add keyboard leds helper app
On Fri, 17 Jan 2014 13:01:20 +0100 Carlos Garnacho carl...@gnome.org wrote: Hey Lennart :), On vie, 2014-01-17 at 12:04 +0100, Lennart Poettering wrote: On Fri, 17.01.14 12:01, Carlos Garnacho (carl...@gnome.org) wrote: This helper program checks the leds available on keyboard devices and exports these as list of keywords in the ID_INPUT_KEYBOARD_LEDS property. The new .rule ensures this helper program runs at the time any keyboard is detected/plugged. What's the usecase for this? Complementing this code, I've got a gnome-settings-daemon patch to show an OSD to hint about *Lock keys being pressed when the keyboard in question does not have leds to tell so. The laptop I got recently has none, and it buggers me when I start yelling without noticing. May be Gnome has something similar? yum info xfce4-kbdleds-plugin ___ Regards, Frank www.frankly3d.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Add keyboard leds helper app
On Fri, 17.01.14 13:01, Carlos Garnacho (carl...@gnome.org) wrote: Hey Lennart :), On vie, 2014-01-17 at 12:04 +0100, Lennart Poettering wrote: On Fri, 17.01.14 12:01, Carlos Garnacho (carl...@gnome.org) wrote: This helper program checks the leds available on keyboard devices and exports these as list of keywords in the ID_INPUT_KEYBOARD_LEDS property. The new .rule ensures this helper program runs at the time any keyboard is detected/plugged. What's the usecase for this? Complementing this code, I've got a gnome-settings-daemon patch to show an OSD to hint about *Lock keys being pressed when the keyboard in question does not have leds to tell so. The laptop I got recently has none, and it buggers me when I start yelling without noticing. Hmm, so the idea here is to attach this information to the udev devices, so that it is available unprivileged? Wouldn't it be more accurate to expose this information via xinput? (Not saying that we shouldn't merge this into udev anyway, just asking...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build: Skip .busname generator when kdbus is off
--- Makefile.am |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index 72da667..7886a81 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1744,6 +1744,7 @@ systemd_gpt_auto_generator_CFLAGS = \ endif # -- +if ENABLE_KDBUS systemgenerator_PROGRAMS += \ systemd-dbus1-generator @@ -1763,6 +1764,7 @@ dbus1-generator-uninstall-hook: INSTALL_EXEC_HOOKS += dbus1-generator-install-hook UNINSTALL_EXEC_HOOKS += dbus1-generator-uninstall-hook +endif # -- systemd_rc_local_generator_SOURCES = \ -- 1.7.2.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Removed Requires=dbus.socket dependency
Hi, ca76186598c56 (Jan 7) has removed the ability to stop all dbus services at once by executing systemctl stop dbus.socket. If that is intentional I can live with it but then we also need to change the man systemd.service and systemd.special as they still mention the dependency to dbus.socket. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] providing backwards compatibility
On 17/01/14 09:42, Kay Sievers wrote: This year will bring huge flag day compat breaks. We will drop all old D-Bus support, we will require on a bleeding edge kernel, and so on. Flag-day compatibility breaks are a massive pain for distributions. The more things need to be upgraded in lockstep, the harder it is - particularly the kernel, since most distributions allow more than one kernel to be installed at a time, and switching the running kernel needs a reboot. Package dependency systems that were mainly designed for libraries and restartable daemons can easily guarantee linux = 3.67 is somewhere in the filesystem, but not linux = 3.67 was booted. I can see that a flag day is sometimes unavoidable, but please do consider it to be a significant cost. In particular, if your goal is for systemd to be a universal part of a standard Linux stack, avoiding flag-day upgrades whenever possible seems wise. I for one would like to be able to assume systemd's technical advantages when writing other software, but distributors who are uneasy about adopting systemd are not going to be reassured by plans that will break their upgrades. The kernel's policy is don't break userspace - isn't the init(1) equivalent don't break the rest of userspace? Regards, S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] providing backwards compatibility
On Fri, Jan 17, 2014 at 2:20 PM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 17/01/14 09:42, Kay Sievers wrote: This year will bring huge flag day compat breaks. We will drop all old D-Bus support, we will require on a bleeding edge kernel, and so on. Flag-day compatibility breaks are a massive pain for distributions. The more things need to be upgraded in lockstep, the harder it is - particularly the kernel, since most distributions allow more than one kernel to be installed at a time, and switching the running kernel needs a reboot. Package dependency systems that were mainly designed for libraries and restartable daemons can easily guarantee linux = 3.67 is somewhere in the filesystem, but not linux = 3.67 was booted. In the kdbus case it's easy, there will be zero backward compat here. Only higher-level users of D-Bus should continue to run without noticing it. Systemd, tools in the base OS, and dbus-daemon will not. I can see that a flag day is sometimes unavoidable, but please do consider it to be a significant cost. In particular, if your goal is for systemd to be a universal part of a standard Linux stack, avoiding flag-day upgrades whenever possible seems wise. I for one would like to be able to assume systemd's technical advantages when writing other software, but distributors who are uneasy about adopting systemd are not going to be reassured by plans that will break their upgrades. We don't break things for fun, but the dependency on kdbus will be hard switch, and there will be no way back. It's unfortunate that this need to happen, but it's worth the pain. There are no alternatives really, as soon as we start using kdbus features, port the journal to kdbus (logging cannot use dbus-daemon because of cyclic deps) the possibility for dbus-daemon to run is over, and with that there will be hard requirement on a recent kernel. The kernel's policy is don't break userspace - isn't the init(1) equivalent don't break the rest of userspace? No it isn't. We need to break things where progress in the base OS is more worth than compatibility. And working for years with enterprise systems, I call the kernel maintainer's claim of not breaking userspace nothing but a dream. It's a good goal, sure, but people just lie to themselves here with statements like forever and such. The kernel/driver break interfaces all the time. All that is reasonable stable is syscalls and old and rather static interfaces like /proc. People doing maintenance as their day job for many years just fix the stuff and don't even tell anybody anymore. Mixing QA and development makes not much sense, and it just doesn't work in reality how people like to believe. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] providing backwards compatibility
On Fri, Jan 17, 2014 at 09:18:49AM +0100, Kay Sievers wrote:
On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
So there's binary compatibility, and source compatibility.
It would be nice if we could do those changes without
a) requiring recompilation (binary)
b) requiring editing build scripts in dependent packages (source).
For b, keeping around a .pc file which points to the *new* library
name should be enough:
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
No, it will clash with the files from the old lib package. We should
not do that, if we no longer provide the same lib.
There's nothing to clash with. Installing two versions of systemd
does not make sense, so we replace one containing the old .pc file,
with a new one, containing a different .pc file. There's no rule
that says that the .pc file must correspond one-to-one to a library.
Irrespective of whether there's a compat libsystemd-login.so in the
system, we want new binaries to link to libsystemd.so.
(Also, note that unless we marge all libraries, including -daemon,
so that there are no libraries sharing the name and so version
between systemd-old and systemd-after-the-merge, it won't be
possible to install even the libraries in parallel, because
e.g. /usr/lib/libsystemd-daemon.so.0 can't point in both directions.)
For a, a compatibility symlink (e.g. libsystemd-login.so.0 -
libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
Same here, it creates clashes with the old files and is not strictly
what it pretends to be with the symlink name.
OK, I buy the argument that this is a lot of magic. Downthread you
suggest, iiuc, to simply install libsystemd-login.so.0 containing a copy
of the code. This should work too and is very easy to implement.
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)
Yes, I think that's the way to go.
This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?
What are we trying to solve here? This is the job of the distro, it is
what it is there for. The distro either leaves the old lib around as
long as needed, or it re-compiles the users to use the new one.
Right now I can switch between systemd-208.rpm and systemd-209-git.rpm
without touching anything else. This is great for the user, and also
great for development. systemd is not really a project to be used
standalone by the user, it only has meaning when it is strongly
supported by other packages. We are nicely positioned in the middle of
everything, with our tentacles reaching into many distributions, so we
can prepare for the change and do it a way that avoid the flag day as
much as possible.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] providing backwards compatibility
On Fri, 17.01.14 15:45, Lennart Poettering (lenn...@poettering.net) wrote: b) The symbols after they have moved must carry a new, correct symbol version, it's not an option to just move the library they are defined in. To explain this: we must provide compatibility for processes that end up linking against both the old and the new library. We must make sure that tis doesn't result in symbol clashes, which means the symbols need to carry different version numbers. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] providing backwards compatibility
On Fri, 17.01.14 13:20, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 17/01/14 09:42, Kay Sievers wrote: This year will bring huge flag day compat breaks. We will drop all old D-Bus support, we will require on a bleeding edge kernel, and so on. Flag-day compatibility breaks are a massive pain for distributions. The Note that it is only some distributions which have a problem with distro-wide changes like this. In Fedoraland it is a lot more common to patch things through the entire distribution or rebuild all users of a library on upgrade. I certainly do understand that Debian does thigns differently here though. The kernel's policy is don't break userspace - isn't the init(1) equivalent don't break the rest of userspace? Well, see the -lrt libc transition. I am not sure we should be held to higher standards there than libc... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Add keyboard leds helper app
On vie, 2014-01-17 at 14:41 +0100, Lennart Poettering wrote: On Fri, 17.01.14 14:19, Carlos Garnacho (carl...@gnome.org) wrote: Hmm, so the idea here is to attach this information to the udev devices, so that it is available unprivileged? Yeah, pretty much. But it is already available in /sys unpriviled, no? See /sys/class/input/*/capabilities/led. Wouldn't that suffice? Hmm, right. It's just capabilities what I'm checking in this case, rather than current state. Checking sysfs would indeed suffice, I'll play out with that in gnome-settings-daemon. Cheers, Carlos ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd-networkd.service.xml src/libsystemd src/network src/systemd units/systemd-networkd.service.in
On Fri, Jan 17, 2014 at 04:18:45PM +0100, Lennart Poettering wrote:
On Thu, 16.01.14 11:32, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
diff --git a/src/network/networkd-manager.c b/src/network/networkd-manager.c
index 3b54214..27f806a 100644
--- a/src/network/networkd-manager.c
+++ b/src/network/networkd-manager.c
@@ -334,7 +334,11 @@ int manager_update_resolv_conf(Manager *m) {
fchmod(fileno(f), 0644);
-fputs(# This file is managed by systemd-networkd(8). Do not
edit.\n, f);
+fputs(# This file is managed by systemd-networkd(8). Do not
edit.\n#\n, f);
+fputs(# Third party programs must not access this file directly,
but\n, f);
+fputs(# only through the symlink at /etc/resolv.conf. To manage
your\n, f);
+fputs(# own static resolv.conf(5), replace the symlink by a
static\n, f);
+fputs(# file at /etc/resolv.conf.\n\n, f);
And if we're already nitpicking:
debian has resolv (or something like that) package, which manages
/etc/resolv.conf
by keeping a volatile file in /var/.../resolv.conf, and a symlink to it in
/etc/resolv.conf.
It would be nice to change the text to accomodate that too, maybe
To manage resolv.conf(5) in a different way, replace the /etc/resolv.conf
symlink
by a static file or a different symlink. systemd-networkd(8) will create the
/etc/resolv.conf symlink if no symlink or file is present there.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd-networkd.service.xml src/libsystemd src/network src/systemd units/systemd-networkd.service.in
On Fri, Jan 17, 2014 at 5:23 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Fri, Jan 17, 2014 at 04:18:45PM +0100, Lennart Poettering wrote:
On Thu, 16.01.14 11:32, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
diff --git a/src/network/networkd-manager.c
b/src/network/networkd-manager.c
index 3b54214..27f806a 100644
--- a/src/network/networkd-manager.c
+++ b/src/network/networkd-manager.c
@@ -334,7 +334,11 @@ int manager_update_resolv_conf(Manager *m) {
fchmod(fileno(f), 0644);
-fputs(# This file is managed by systemd-networkd(8). Do not
edit.\n, f);
+fputs(# This file is managed by systemd-networkd(8). Do not
edit.\n#\n, f);
+fputs(# Third party programs must not access this file directly,
but\n, f);
+fputs(# only through the symlink at /etc/resolv.conf. To manage
your\n, f);
+fputs(# own static resolv.conf(5), replace the symlink by a
static\n, f);
+fputs(# file at /etc/resolv.conf.\n\n, f);
And if we're already nitpicking:
debian has resolv (or something like that) package, which manages
/etc/resolv.conf
by keeping a volatile file in /var/.../resolv.conf, and a symlink to it in
/etc/resolv.conf.
It would be nice to change the text to accomodate that too, maybe
To manage resolv.conf(5) in a different way, replace the /etc/resolv.conf
symlink
by a static file or a different symlink. systemd-networkd(8) will create the
/etc/resolv.conf symlink if no symlink or file is present there.
Systemd should not create /etc/resolv.conf. The entire concept of
it is too broken to be supported by systemd.
We should only provide a hidden and private copy in /run, which the
*admin* can use as long as it's still needed.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] providing backwards compatibility
On Fri, Jan 17, 2014 at 03:45:03PM +0100, Lennart Poettering wrote:
On Fri, 17.01.14 04:06, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
So there's binary compatibility, and source compatibility.
It would be nice if we could do those changes without
a) requiring recompilation (binary)
b) requiring editing build scripts in dependent packages (source).
For b, keeping around a .pc file which points to the *new* library
name should be enough:
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
For a, a compatibility symlink (e.g. libsystemd-login.so.0 -
libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
So here's my opinion on all of this:
First let me say that I am pretty strongly of the belief that API+ABI
breaks are something that distros have to deal with, it's one of the
primary reasons distros exist, so that they can deal with things like
this across the whole system. For example, recently glibc reorganized
-lrt, and if they can do that, we certainly can do this too.
That said, while I believe that distros must be prepared to deal with
this, I think we can certainly help to make this easy for them, and make
the transition gradual rather than abrupt. However, for us upstream a
couple of things matter:
a) I don't want legacy/dead code in our upstream repo that we don't use
and hence test regularly. Thus I don't think it is an option to
simply keep two copies of everything in our repo, once for the old
and once for the new library.
b) The symbols after they have moved must carry a new, correct symbol
version, it's not an option to just move the library they are defined
in.
c) Manual symblinks between libraries are not an option I think, this
will break too easily, and will likely confuse tools like ldconfig...
d) Compatibility for the old library names and versions must be
isolated in the source tree, and it must be clear that we can remove this
easily within a year or so.
OK.
So, here's what I'd propose to maintain compatibility in both API and
ABI for a year or so:
1) Merge the libraries now. Give everything new symbol versions.
2) Expose the sd-bus/sd-event/sd-memfd/ symbols only if --enable-kdbus
is specified. People who enable this will hence get a different API
for this library than others! This is OK I think, by specifying
--enable-kdbus users basically declare that they know that there are
no API/ABI guarantees.
3) The new library will ship one .pc file only.
4) In a new subdirectory src/compat-libs/ (or something like that) we
will provide compat stubs that will build libraries (for ABI compat)
and pc files (for API compat) that redirect to
the new versions. This stuff should be optional though, and only be
enabled if --enable-compat-libs is specified, and the README should
name a date when this will be removed.
OK.
Now, the way I'd propose the stub libs of item #4 to be implemented is
via a combination of .symver asm magic, and the ifunc function
attribute. With a script we'd first generate for every old symbol code
like the following:
void new_sd_id128_from_string(void);
__asm__(.symver
new_sd_id128_from_string,sd_id128_from_string@LIBSYSTEMD_209);
This would define a new symbol new_sd_id128_from_string which refers to
the specific version of the function from thew new library. Note that we
don't care for the right function signature, we only care for the naked
symbol name, that's all.
Then, we'd use ifunc to define a local function with the right name,
that just maps to the new implementation:
static void (*resolve_sd_id128_from_string (void)) (void) {
return new_sd_id128_from_string;
}
void sd_id128_from_string(void)
__attribute__((ifunc(resolve_sd_id128_from_string)));
This newly defined function would then be assigned the right old version
with the .sym file, as before.
This sounds like a good plan.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd-networkd.service.xml src/libsystemd src/network src/systemd units/systemd-networkd.service.in
On Fri, Jan 17, 2014 at 05:34:45PM +0100, Kay Sievers wrote: Systemd should not create /etc/resolv.conf. The entire concept of it is too broken to be supported by systemd. We should only provide a hidden and private copy in /run, which the *admin* can use as long as it's still needed. Well, I know that /etc/resov.conf is deficient, but we have no replacement right now, and without a resolv.conf, a network connection is rather useless. In general various systemd components work out of the box where reasonable. It would be much nicer to be able to do 'rm /etc/resolv.conf systemctl start systemd-networkd' to get a working network. Even systemd-nspawn does this, I don't see why systemd-networkd shouldn't. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd-networkd.service.xml src/libsystemd src/network src/systemd units/systemd-networkd.service.in
On Fri, Jan 17, 2014 at 5:51 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Fri, Jan 17, 2014 at 05:34:45PM +0100, Kay Sievers wrote: Systemd should not create /etc/resolv.conf. The entire concept of it is too broken to be supported by systemd. We should only provide a hidden and private copy in /run, which the *admin* can use as long as it's still needed. Well, I know that /etc/resov.conf is deficient, but we have no replacement right now, and without a resolv.conf, a network connection is rather useless. In general various systemd components work out of the box where reasonable. It would be much nicer to be able to do 'rm /etc/resolv.conf systemctl start systemd-networkd' to get a working network. Even systemd-nspawn does this, I don't see why systemd-networkd shouldn't. Simple reason is that it is too broken to be maintained by systemd tools. We also do not ship any default network config, networkd is just dead by default. We should not even start touching /etc/resolv.conf, we would break it later anyway, and should avoid all that right from the beginning. It is not a reasonable technology to carry on or support like /etc/fstab. /etc/resolv.conf should entirely be admin territory like /etc/hosts, and will win over all other settings. No tool should mangle it, especially when it's not there. It is actually the goal to get rid of it, not to create it. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd-networkd.service.xml src/libsystemd src/network src/systemd units/systemd-networkd.service.in
On Fri, Jan 17, 2014 at 05:57:20PM +0100, Kay Sievers wrote: On Fri, Jan 17, 2014 at 5:51 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Fri, Jan 17, 2014 at 05:34:45PM +0100, Kay Sievers wrote: Systemd should not create /etc/resolv.conf. The entire concept of it is too broken to be supported by systemd. We should only provide a hidden and private copy in /run, which the *admin* can use as long as it's still needed. Well, I know that /etc/resov.conf is deficient, but we have no replacement right now, and without a resolv.conf, a network connection is rather useless. In general various systemd components work out of the box where reasonable. It would be much nicer to be able to do 'rm /etc/resolv.conf systemctl start systemd-networkd' to get a working network. Even systemd-nspawn does this, I don't see why systemd-networkd shouldn't. Simple reason is that it is too broken to be maintained by systemd tools. We also do not ship any default network config, networkd is just dead by default. We should not even start touching /etc/resolv.conf, we would break it later anyway, and should avoid all that right from the beginning. It is not a reasonable technology to carry on or support like /etc/fstab. /etc/resolv.conf should entirely be admin territory like /etc/hosts, and will win over all other settings. No tool should mangle it, especially when it's not there. It is actually the goal to get rid of it, not to create it. OK, OK. So maybe: To manage resolv.conf(5) in a different way, replace the /etc/resolv.conf symlink by a static file or a different symlink. :) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd-networkd.service.xml src/libsystemd src/network src/systemd units/systemd-networkd.service.in
On Fri, 17.01.14 17:57, Kay Sievers (k...@vrfy.org) wrote: Simple reason is that it is too broken to be maintained by systemd tools. We also do not ship any default network config, networkd is just dead by default. We should not even start touching /etc/resolv.conf, we would break it later anyway, and should avoid all that right from the beginning. It is not a reasonable technology to carry on or support like /etc/fstab. /etc/resolv.conf should entirely be admin territory like /etc/hosts, and will win over all other settings. No tool should mangle it, especially when it's not there. It is actually the goal to get rid of it, not to create it. I am pretty sure that systemd upstream shouldn't create the link, but I'd expect that the systemd RPM postinst scriplet would create it, if /etc/resolv.conf doesn't exist yet. I mean, this is really something where distros should decide what they want, but we shouldn't push them too hard by encoding something in make install, since this is compat stuff... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus: Fix read_word_le() function
---
src/libsystemd/bus-message.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd/bus-message.c b/src/libsystemd/bus-message.c
index 0c8604c..1a2039b 100644
--- a/src/libsystemd/bus-message.c
+++ b/src/libsystemd/bus-message.c
@@ -1935,7 +1935,7 @@ static size_t read_word_le(void *p, size_t sz) {
return le16toh(x.u16);
else if (sz == 4)
return le32toh(x.u32);
-else if (sz == 4)
+else if (sz == 8)
return le64toh(x.u64);
assert_not_reached(unknown word width);
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/4] gdbus: Add basic kdbus tests
On 12/20/2013 04:23 PM, Yin Kangkai wrote: Will it be more interesting to show some real benchmarking numbers? ;) - results with vanilla GIO; - results with GIO with kdbus transport, talking to kdbus dbus-daemon; - results with GIO with kdbus transport, talking through systemd-bus-proxyd to systemd-bus-driverd; Regards, Kangkai Hi Kangkai, Here you can find some real benchmarking numbers: http://lists.freedesktop.org/archives/dbus/2014-January/016074.html -- Lukasz Skalski Samsung RD Institute Poland Samsung Electronics l.skal...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Do not warn on declaration-after-statement
From: Michael Scherer m...@zarb.org There is currently around 20 instances of the warning shown when compiling systemd on Fedora 20, and no one seems to correct them. As this is a valid C code for C99 and gcc support C99 since 3.0 ( ie more than 10 years ), it may not be worth showing this warning. --- configure.ac | 1 - 1 file changed, 1 deletion(-) diff --git a/configure.ac b/configure.ac index 939ba6d..3a21a77 100644 --- a/configure.ac +++ b/configure.ac @@ -127,7 +127,6 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ -Wold-style-definition \ -Wpointer-arith \ -Winit-self \ --Wdeclaration-after-statement \ -Wfloat-equal \ -Wsuggest-attribute=noreturn \ -Wmissing-prototypes \ -- 1.8.4.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Fix read_word_le() function
On Fri, 17.01.14 18:11, Lukasz Skalski (l.skal...@partner.samsung.com) wrote:
Applied!
Thanks!
---
src/libsystemd/bus-message.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd/bus-message.c b/src/libsystemd/bus-message.c
index 0c8604c..1a2039b 100644
--- a/src/libsystemd/bus-message.c
+++ b/src/libsystemd/bus-message.c
@@ -1935,7 +1935,7 @@ static size_t read_word_le(void *p, size_t sz) {
return le16toh(x.u16);
else if (sz == 4)
return le32toh(x.u32);
-else if (sz == 4)
+else if (sz == 8)
return le64toh(x.u64);
assert_not_reached(unknown word width);
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Do not warn on declaration-after-statement
On Fri, 17.01.14 18:25, m...@zarb.org (m...@zarb.org) wrote: From: Michael Scherer m...@zarb.org There is currently around 20 instances of the warning shown when compiling systemd on Fedora 20, and no one seems to correct them. As this is a valid C code for C99 and gcc support C99 since 3.0 ( ie more than 10 years ), it may not be worth showing this warning. We generally try to avoid declarations after statements in our coding style, which is the reason why this warning is on. Note that this warning you see only happens on some gcc versions, i.e. versions where C11 static_assert()s is new. Older versions which lack support for it, and newer versions will not generate the warning. I am hence inclined to leave this on, really... --- configure.ac | 1 - 1 file changed, 1 deletion(-) diff --git a/configure.ac b/configure.ac index 939ba6d..3a21a77 100644 --- a/configure.ac +++ b/configure.ac @@ -127,7 +127,6 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ -Wold-style-definition \ -Wpointer-arith \ -Winit-self \ --Wdeclaration-after-statement \ -Wfloat-equal \ -Wsuggest-attribute=noreturn \ -Wmissing-prototypes \ Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Do not warn on declaration-after-statement
On Fri, Jan 17, 2014 at 06:58:01PM +0100, Lennart Poettering wrote: On Fri, 17.01.14 18:25, m...@zarb.org (m...@zarb.org) wrote: From: Michael Scherer m...@zarb.org There is currently around 20 instances of the warning shown when compiling systemd on Fedora 20, and no one seems to correct them. As this is a valid C code for C99 and gcc support C99 since 3.0 ( ie more than 10 years ), it may not be worth showing this warning. We generally try to avoid declarations after statements in our coding style, which is the reason why this warning is on. Note that this warning you see only happens on some gcc versions, i.e. versions where C11 static_assert()s is new. Older versions which lack support for it, and newer versions will not generate the warning. Hm, I have gcc-4.8.2-7.fc20.x86_64. In version is this fixed? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Removed Requires=dbus.socket dependency
On Fri, 17.01.14 14:12, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: Hi, ca76186598c56 (Jan 7) has removed the ability to stop all dbus services at once by executing systemctl stop dbus.socket. If that is intentional I can live with it but then we also need to change the man systemd.service and systemd.special as they still mention the dependency to dbus.socket. dbus.socket is really just about the socket, nothing else. It's not supposed to be used as a target unit really. The thing is that dbus.socket doesn't make much sense anymore for processes that connect via kdbus, which is why we removed it. Moreover for systems that use dbus-daemon instead of kdbus it's kinda pointless too, because for early-boot services dbus is simply not available on such systems, and depending on the socket unit won't change that and for normal non-early-boot services the dependency is implicitly there via basic.target (which depends on sockets.target)... So yupp, this is an intended change. I added to the TODO list, that we'll update the man page accordingly. Thanks for the pointer! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: Skip .busname generator when kdbus is off
On Fri, 17.01.14 13:34, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: Thanks! Applied! --- Makefile.am |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index 72da667..7886a81 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1744,6 +1744,7 @@ systemd_gpt_auto_generator_CFLAGS = \ endif # -- +if ENABLE_KDBUS systemgenerator_PROGRAMS += \ systemd-dbus1-generator @@ -1763,6 +1764,7 @@ dbus1-generator-uninstall-hook: INSTALL_EXEC_HOOKS += dbus1-generator-install-hook UNINSTALL_EXEC_HOOKS += dbus1-generator-uninstall-hook +endif # -- systemd_rc_local_generator_SOURCES = \ Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv5] tmpfiles, man: Add xattr support to tmpfiles
On Thu, 16.01.14 15:42, Maciej Wereski (m.were...@partner.samsung.com) wrote:
11.12.2013 at 15:15 Lennart Poettering lenn...@poettering.net wrote:
On Wed, 11.12.13 14:24, Maciej Wereski
(m.were...@partner.samsung.com) wrote:
+xattr = new0(char, strlen(i-argument)+1);
+if (!xattr)
+return log_oom();
+
+tmp = strv_split(i-argument, WHITESPACE);
+if (!tmp)
+return log_oom();
+
+strv_len = strv_length(tmp);
+for (n = 0; n strv_len; ++n) {
Sounds like a job for the STRV_FOREACH() macro. Since you don't
actually
need the strv as strv here it sounds like you actually really want to
use FOREACH_WORD_QUOTED() for this, which will also do the
unquoting for
you.
Well, FOREACH_WORD_QUOTED() won't work properly, because quotation marks
aren't first chars in strings (e.g. user.name=John Smith).
Maybe better
idea would be to introduce mandatory separator (e.g. semicolon)
instead of
quotation marks.
Yeah, FOREACH_WORD_QUOTED() is quite badly designed. We should fix it to
do somewhat sane quoting and escaping. I'll look into it.
There is one problem with using it in this patch. In my case
quotation mark isn't first char of the string, so using pointer and
length won't get rid of it. String needs to be modified.
Yeah, this has been a long-standing issue actually, the unquoting logic
is pretty broken here, we should probably rework FOREACH_WORD_QUOTED()
to allocate a buffer for this and do proper unquoting. I have been
planning to do this for a while.
In fact, we should probably have a closer look that we implement similar
quoting rules for all file formats we define.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2][RFC] sd-resolve: rename structs to fit coding-style e.g 'struct MixedCase'
On Wed, 15.01.14 18:21, Daniel Buch (boogiewasth...@gmail.com) wrote: lets get this right once, and if not for all, atleast for now :) So comments and input about nameing is very welcome. Both patches look good. Applied! On a related note: i added a couple of items to the TODO list of changes I'd still like to see in sd-resolve.h before we do a release, so that the API feels more like the other APIs. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] understanding list-unit-files ...
On Wed, 15.01.14 16:20, Holger Schurig (holgerschu...@gmail.com) wrote: There is one strange thing here: root@desktop:/etc# systemctl list-unit-files | grep multi multi-user.targetdisabled root@desktop:/etc# systemctl status multi-user.target multi-user.target - Multi-User System Loaded: loaded (/lib/systemd/system/multi-user.target; disabled) Active: active since Wed 2014-01-15 15:22:14 CET; 56min ago Docs: man:systemd.special(7) 15:22:14 systemd[1]: Starting Multi-User System. 15:22:14 systemd[1]: Reached target Multi-User System. root@desktop:/etc# So, why is list-unit-files saying that multi-user.target is disabled? It's not, it was even started automatically ... Yeah, this is quite misleading indeed. It is casued by the [Install] section in the units, which are supposed to useful to to switch the default.target symlink by enabling/disabling the units. Given that this is so confusing, and that we now have systemctl set-default that is much nicer for this, I have now removed the [Install] section from these unit files, so that they will appear as static. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-resolv: declare functions from .h public
On Tue, 14.01.14 19:29, Tom Gundersen (t...@jklm.no) wrote: Hi Daniel, I guess we should only do this once we decide to export the API. I guess we won't be doing that for a few releases (we'll use it internally first to make sure it is the way we want it). Or are there any benefits to these annotations even when the symbols are not exported? Well, sd-resolve is in the same situation here as sd-event or sd-bus are: not public APIs yet, but probably very soon. And given that sd-event, sd-bus, sd-memfd, ... all have the _public_ stuff sd-resolve.h probably should too. I'd merge the patch, alas it doesn't apply anymore. Daniel, could you rebase please? Also, the symbols exposed by sd_resolve need to be added to the .sym file, too. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Merging journal logs from btrfs snapshots
Chris Murphy li...@colorremedies.com schrieb: I tend to keep the original boot, root, home subvolumes as primary. So I think it's a bit weird having FS_TREE/root/var/log/journal as a subvolume that is then mounted on top of itself most of the time - as that's the way it would be in order for the fstab of subsequent root snapshots to mount the journal subvolume. Otherwise I'd have to change the fstab for each snapshot = annoying. So I think I'd put the journal subvolume in top level 5, or maybe in some other tree for persistent subvolumes to mount. You understood me wrong but I think we tend to mean the same. ;-) But it won't get mounted on top of itself. If this is your structure: FS_TREE var-log-journal -- this is your journal subvolume rootfs -- rw snapshot aka subvolume var log journal-- this is an empty directory ... home -- subvolume Then you would have in FS_TREE/rootfs/etc/fstab always the same mount point for the journal: LABEL=btrfs-pool / subvol=rootfs LABEL=btrfs-pool /home subvol=home LABEL=btrfs-pool /var/log/journal subvol=var-log-journal,x-systemd.automount I understood you that it was all about having the journal independent of snapshots taken of rootfs. You are right about taking snapshots ro, then rollback by snapshotting rw. These are implementation details which would make this even more complicate to follow. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
On Tue, 14.01.14 13:31, Barry Scott (barry.sc...@onelan.co.uk) wrote: systemd-208-9.fc20.x86_64 We have been porting a working configuration from fedora 19 to fedora 20. After systemd prints the Welcome message it then hangs. What do you mean by hangs? Is it just the output that doesn't continue anymore or does the entire system lock up? Note that during really early boot the journal is not available yet, which means we can only log to kmsg then (and thus the console). However, as soon as the journal is available we then start logging directly to the journal. This might appear from the outside as if only during the first part of the boot output is generated if you only look at the console. You can use LogTarget=kmsg to redirect output to kmsg unconditionally, so that you get everything in kmsg and thus the console. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd-networkd.service.xml src/libsystemd src/network src/systemd units/systemd-networkd.service.in
On Fri, Jan 17, 2014 at 4:18 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 16.01.14 11:32, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
diff --git a/src/network/networkd-manager.c b/src/network/networkd-manager.c
index 3b54214..27f806a 100644
--- a/src/network/networkd-manager.c
+++ b/src/network/networkd-manager.c
@@ -334,7 +334,11 @@ int manager_update_resolv_conf(Manager *m) {
fchmod(fileno(f), 0644);
-fputs(# This file is managed by systemd-networkd(8). Do not
edit.\n, f);
+fputs(# This file is managed by systemd-networkd(8). Do not
edit.\n#\n, f);
+fputs(# Third party programs must not access this file directly,
but\n, f);
+fputs(# only through the symlink at /etc/resolv.conf. To manage
your\n, f);
+fputs(# own static resolv.conf(5), replace the symlink by a
static\n, f);
+fputs(# file at /etc/resolv.conf.\n\n, f);
Just some nitpicking: why do this with 5 function calls instead of just
one?
Just me being stupid. Will push a fix shortly.
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 7 commits - man/systemd-networkd.service.xml src/libsystemd src/network src/systemd units/systemd-networkd.service.in
On Fri, Jan 17, 2014 at 6:07 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Fri, Jan 17, 2014 at 05:57:20PM +0100, Kay Sievers wrote: On Fri, Jan 17, 2014 at 5:51 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Fri, Jan 17, 2014 at 05:34:45PM +0100, Kay Sievers wrote: Systemd should not create /etc/resolv.conf. The entire concept of it is too broken to be supported by systemd. We should only provide a hidden and private copy in /run, which the *admin* can use as long as it's still needed. Well, I know that /etc/resov.conf is deficient, but we have no replacement right now, and without a resolv.conf, a network connection is rather useless. In general various systemd components work out of the box where reasonable. It would be much nicer to be able to do 'rm /etc/resolv.conf systemctl start systemd-networkd' to get a working network. Even systemd-nspawn does this, I don't see why systemd-networkd shouldn't. Simple reason is that it is too broken to be maintained by systemd tools. We also do not ship any default network config, networkd is just dead by default. We should not even start touching /etc/resolv.conf, we would break it later anyway, and should avoid all that right from the beginning. It is not a reasonable technology to carry on or support like /etc/fstab. /etc/resolv.conf should entirely be admin territory like /etc/hosts, and will win over all other settings. No tool should mangle it, especially when it's not there. It is actually the goal to get rid of it, not to create it. OK, OK. So maybe: To manage resolv.conf(5) in a different way, replace the /etc/resolv.conf symlink by a static file or a different symlink. So I agree with Lennart and Kay that we should not create this symlink, but leave that to the distro/admin. I'll change the wording as you suggest though, makes sense to be more general here. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
On Fri, Jan 17, 2014 at 12:17 PM, Lennart Poettering lenn...@poettering.net wrote: Note that during really early boot the journal is not available yet, which means we can only log to kmsg then (and thus the console). However, as soon as the journal is available we then start logging directly to the journal. This might appear from the outside as if only during the first part of the boot output is generated if you only look at the console. The way we're seeing it manifest as freezes for 60 seconds a line in bootup. After each 60 second timeout, we see a single line of kmsg output, and then bootup continues until another item gets logged. You can use LogTarget=kmsg to redirect output to kmsg unconditionally, so that you get everything in kmsg and thus the console. This seems to have major performance impacts versus logging to the journal. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hangs after Welcome message when LogLevel=debug
It would be nice if bootup could realize the journal queue is full and wait for journal startup before proceeding further. It might cause some annoying non-determinism, though. We primarily see the problem with the logging from automounts and mount units. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] .socket in a network namespace
Hello, Is there a way to have a .socket bind in a particular network namespace? The use case is to have a container with isolated networking be able to start a service, or tunnel to a remote service, that exists outside the containers namespace. Thank you for any leads. I could not find anything related to this in the documentation. Regards, -Alex ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
