Re: [systemd-devel] Moving systemd-bootchart to a standalone repository
On 17.2.2016 20:02, Umut Tezduyar Lindskog wrote: Hi, src/shared & src/basic have very useful code that upstream have been static linking to most binaries. My understanding is that we haven’t been feeling comfortable about the API to make these paths a standalone library (or include them in libsystemd). Now that we started duplicating the code outside of systemd main repo, wouldn’t it be wise to make it a library even if it was something like libsystemd_onlyandonlyinternal.so. For people who can follow upstream’s speed and catch up with API changes we would gain: A) No duplication of useful code. B) Reduce the binary sizes. Umut More like a separate project that can be imported as submodule where necessary (say, like gnulib). Probably nobody has any will to make that happen though. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v229
On 12.02.2016 10:54, Colin Guthrie wrote:
> Dave Reisner wrote on 12/02/16 01:09:
>> On Thu, Feb 11, 2016 at 10:26:51PM +0100, Reindl Harald wrote:
>>>
>>> Am 11.02.2016 um 22:19 schrieb Dave Reisner:
On Thu, Feb 11, 2016 at 05:50:08PM +0100, Lennart Poettering wrote:
> I just tagged the v229 release of systemd. Enjoy!
>
> CHANGES WITH 229:
>
>
>
> * When the stacktrace is extracted from processes of system
> users, this
> is now done as "systemd-coredump" user, in order to sandbox this
> potentially security sensitive parsing operation. (Note that
> when
> processing coredumps of normal users this is done under the
> user ID
> of process that crashed, as before.) Packagers should take
> notice
> that it is now necessary to create the "systemd-coredump"
> system user
> and group at package installation time.
>
Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
>>>
>>> systemd don't create any user. nowhere, rpm-scritrs downstream does
>>
>> You're mistaken. See /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf
>> and
>> systemd-sysusers(8). The curious absence of systemd-coredump from
>> sysusers.d/systemd.conf is what I'm asking about here.
>
> Seems odd indeed. It's perhaps because the user needs to own directories
> that are packaged (e.g. in /var) which is somewhat tricky with sysusers
> - you need to have the user available before the package is installed -
> i.e. an RPM %pre script. Just a guess at why it was left out.
>
> Personally, I'd just make such folders ghosts and them have them created
> by tmpfiles after package install (and thus after sysusers has run to
> create the user who will own the folders)
>
> This is something that I think should be automated in RPM packaging
> (i.e. the creation of ghosts automatically by parsing packaged tmpfiles
> snippets), but this is off-topic.
>
> Col
>
>
>
>
I don't see the problem. The user is already in sysusers.d/systemd.conf.m4
https://github.com/systemd/systemd/blob/master/sysusers.d/systemd.conf.m4
I do appreciate that he mentioned a new user had to be created, because,
you know, not everyone uses systemd-sysusers.
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] the chopping block
On 11.02.2016 20:44, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 11, 2016 at 06:45:52PM +0100, Lennart Poettering wrote:
>> On Thu, 11.02.16 17:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
>> wrote:
>>
>>> On Thu, Feb 11, 2016 at 06:06:45PM +0100, Lennart Poettering wrote:
Heya!
So I am thinking about some spring cleaning, and would love to remove
the following bits from the systemd package:
1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
time Debian was still using that, maybe this changed now?
2) compat support for libsystemd-login.so and friends (these were
merged into a single libsystemd.so a long time ago). We are still
building compat libraries to ease the transition, but that was a
long time ago, hence I'd really love to see this go. Any distro
still using this?
>>> Fedora ;)
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1125086
>>> But looking at https://bugzilla.samba.org/show_bug.cgi?id=10672#c14
>>> maybe it'd be enough to rebuild samba without the compat headers
installed.
>>
>> As long as it's only one package I am happy to break this I must say...
> I check this now, and samba compiles fine with systemd-compat-libs.rpm
> removed. So no problem here.
>
> Our compat support consists of two parts:
> libsystemd-{journal,daemon,...}.pc and the .so libraries. I think we
> should still keep the .pc files for now.
Yes, please! I've been doing just that ever since libsystemd was introduced.
Sadly, the change to always install .pc files even when libraries weren't
built was rejected.
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] the chopping block
On 11.02.2016 21:04, Jóhann B. Guðmundsson wrote: > > > On 02/11/2016 05:34 PM, Zbigniew Jędrzejewski-Szmek wrote: >>> >2) compat support for libsystemd-login.so and friends (these were >>> >merged into a single libsystemd.so a long time ago). We are still >>> >building compat libraries to ease the transition, but that was a >>> >long time ago, hence I'd really love to see this go. Any distro >>> >still using this? >> Fedora;) >> https://bugzilla.redhat.com/show_bug.cgi?id=1125086 >> But looking athttps://bugzilla.samba.org/show_bug.cgi?id=10672#c14 >> maybe it'd be enough to rebuild samba without the compat headers installed. >> > > The upstream bug is few months short of it's 2 year anniversary and this move > will just get the samba developers to apply the patch in that upstream report > and close that bug. > > Andrew is there any reason the patch in that upstream report has not been > applied and samba moved to use libsystemd.so? It has been applied at least since the last summer. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should pam-activated systemd --user daemon quit after session has been closed?
Bump. On 22.01.2016 23:19, Armin K. wrote: > Hi, > > I have a following problem on my system and it has been bothering me for some > time. > > I use KDE Plasma 5 and lightdm as a display manager to login to the session. > Once > logged in, the lightdm (I guess it's using pam_systemd.so) login service will > also > start systemd user session and a session dbus daemon. The rest of Plasma > follows. > > The problem is, that whenever I log out from Plasma, the systemd user session > isn't > terminated and as such leaves the user bus daemon and lots of services > around, which > makes shutdown hang (if I initiated the shutdown, which will first initiate > log out) > for some time (90 seconds by default until it's forcibly killed by systemd) > which > I rather find annoying. I can see the systemd user session is the culprit, > because > I can see "Waiting for session for user 1000 to terminate [timer]" or > something > like that. > > When I just log out, I can manually stop the systemd user session using > loginctl > kill-user/kill-session (I am not sure which one I used last time), which will > terminate > user bus and all the other services from that session. > > Now, to the original question: Once PAM closes the session (once logout is > received), > should systemd --user daemon terminate as well? Currently, that's not the > case on my > system. > > Let me know if I can provide any additional info. > > Cheers > signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should pam-activated systemd --user daemon quit after session has been closed?
On 23.1.2016 8:00, Andrei Borzenkov wrote: 23.01.2016 01:19, Armin K. пишет: Now, to the original question: Once PAM closes the session (once logout is received), should systemd --user daemon terminate as well? Currently, that's not the case on my system. As far as I understand systemd --user instance is supposed to be per-user, not per-session. So I tentatively say this behavior is correct. Even in this case, once the user logs out completely, the behavior is as described. This has only been happening since last couple releases (I think 226 was fine). It was fine, now it's broken and I have no idea what or who broke it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Variables in the [Unit] section of a server
> On 01/13/2016 10:51 AM, Steve Dickson wrote:
>> Hello,
>>
>> Is is possible to set a variable in the [Unit]
>> section of a service?
>>
>> For example in rpc-gssd.service there is
>> ConditionPathExists=/etc/krb5.keytab
>>
>> but for some installation the krb5.keytab
>> is in a different place. The rpc.gssd daemon
>> can be told this by setting a command line
>> argument from the EnvironmentFile.
>>
>> So people have to edit both the EnvironmentFile
>> and the rpc-gssd.service to make this change.
>>
>> So it would be nice if only the EnvironmentFile
>> need to be edit and the change would happen
>> in both places.
>>
>> Possible?
>>
>> steved.
I'm sorry I'm not responding to the original mail, as I just subscribed
yesterday to this list.
I am not sure I fully understand what you want, but I think this might do it:
[Unit]
Description=test
[Service]
Type=oneshot
Environment=TEST=blah
EnvironmentFile=-/etc/systemd/system/test-env
ExecStart=/etc/systemd/system/test ${TEST}
TimeoutSec=0
RemainAfterExit=yes
The /etc/systemd/system/test is a script that prints $1, depending on what is
being passed to it. When env file is not present, it prints the TEST from the
unit file. When env file is present, and TEST is set to something else, it
prints its value. Is that what you are looking for?
Cheers
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Variables in the [Unit] section of a server
On 23.01.2016 17:28, Armin K. wrote:
>> On 01/13/2016 10:51 AM, Steve Dickson wrote:
>>> Hello,
>>>
>>> Is is possible to set a variable in the [Unit]
>>> section of a service?
>>>
>>> For example in rpc-gssd.service there is
>>> ConditionPathExists=/etc/krb5.keytab
>>>
>>> but for some installation the krb5.keytab
>>> is in a different place. The rpc.gssd daemon
>>> can be told this by setting a command line
>>> argument from the EnvironmentFile.
>>>
>>> So people have to edit both the EnvironmentFile
>>> and the rpc-gssd.service to make this change.
>>>
>>> So it would be nice if only the EnvironmentFile
>>> need to be edit and the change would happen
>>> in both places.
>>>
>>> Possible?
>>>
>>> steved.
>
> I'm sorry I'm not responding to the original mail, as I just subscribed
> yesterday to this list.
>
> I am not sure I fully understand what you want, but I think this might do it:
>
> [Unit]
> Description=test
>
> [Service]
> Type=oneshot
> Environment=TEST=blah
> EnvironmentFile=-/etc/systemd/system/test-env
> ExecStart=/etc/systemd/system/test ${TEST}
> TimeoutSec=0
> RemainAfterExit=yes
>
> The /etc/systemd/system/test is a script that prints $1, depending on what is
> being passed to it. When env file is not present, it prints the TEST from the
> unit file. When env file is present, and TEST is set to something else, it
> prints its value. Is that what you are looking for?
>
> Cheers
>
Ugh, sorry. You asked for the [Unit] section, not the [Service] section.
From what I see, it doesn't yet seem to be possible:
[/etc/systemd/system/test.service:2] Unknown lvalue 'Environment' in section
'Unit'
[/etc/systemd/system/test.service:4] Path in condition not absolute, ignoring:
$TEST
You can always use some kind of hackery in ExecStartPre, but I don't think
that's
what anyone wants.
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Should pam-activated systemd --user daemon quit after session has been closed?
Hi, I have a following problem on my system and it has been bothering me for some time. I use KDE Plasma 5 and lightdm as a display manager to login to the session. Once logged in, the lightdm (I guess it's using pam_systemd.so) login service will also start systemd user session and a session dbus daemon. The rest of Plasma follows. The problem is, that whenever I log out from Plasma, the systemd user session isn't terminated and as such leaves the user bus daemon and lots of services around, which makes shutdown hang (if I initiated the shutdown, which will first initiate log out) for some time (90 seconds by default until it's forcibly killed by systemd) which I rather find annoying. I can see the systemd user session is the culprit, because I can see "Waiting for session for user 1000 to terminate [timer]" or something like that. When I just log out, I can manually stop the systemd user session using loginctl kill-user/kill-session (I am not sure which one I used last time), which will terminate user bus and all the other services from that session. Now, to the original question: Once PAM closes the session (once logout is received), should systemd --user daemon terminate as well? Currently, that's not the case on my system. Let me know if I can provide any additional info. Cheers signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should pam-activated systemd --user daemon quit after session has been closed?
On 22.01.2016 23:35, Kai Krakow wrote: > Am Fri, 22 Jan 2016 23:19:11 +0100 > schrieb "Armin K." <kre...@email.com>: > >> I have a following problem on my system and it has been bothering me >> for some time. >> >> I use KDE Plasma 5 and lightdm as a display manager to login to the >> session. Once logged in, the lightdm (I guess it's using >> pam_systemd.so) login service will also start systemd user session >> and a session dbus daemon. The rest of Plasma follows. >> >> The problem is, that whenever I log out from Plasma, the systemd user >> session isn't terminated and as such leaves the user bus daemon and >> lots of services around, which makes shutdown hang (if I initiated >> the shutdown, which will first initiate log out) for some time (90 >> seconds by default until it's forcibly killed by systemd) which I >> rather find annoying. I can see the systemd user session is the >> culprit, because I can see "Waiting for session for user 1000 to >> terminate [timer]" or something like that. >> >> When I just log out, I can manually stop the systemd user session >> using loginctl kill-user/kill-session (I am not sure which one I used >> last time), which will terminate user bus and all the other services >> from that session. >> >> Now, to the original question: Once PAM closes the session (once >> logout is received), should systemd --user daemon terminate as well? >> Currently, that's not the case on my system. >> >> Let me know if I can provide any additional info. > > Have you tried SDDM instead of LightDM... SDDM is recommended for KDE > Plasma 5 afaik. I had similar issues with shutdown when I still used > LightDM. Tho I never tracked it back due to an orphan user session - > good catch. > I've tried SDDM, but due to bug that's present up to this day [1], I was unable to continue using it. Lightdm is the only viable alternative it seems. Now, again to my problem. I have just set KillUserProcesses=yes in /etc/systemd/logind.conf and can confirm that the user processes are killed after I log out. But the original problem persists. The systemd --user daemon and (sd-pam) process still remain running after logout for some 20 seconds, after which it will terminate itself cleanly. Not a big issue (certainly beats hanging forever), but still an annoying one as it would block shutdown for that amount of time. I can understand why KillUserProcesses=yes isn't set by default, but is it possible to add a parameter to pam_systemd.so when used for certain service to kill all the processes? I think I saw something a good while ago, but can't find anything in pam_systemd(8). [1] https://github.com/sddm/sddm/issues/286 (yes, I use gnome-keyring in KDE) signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should pam-activated systemd --user daemon quit after session has been closed?
On 23.01.2016 00:17, Kai Krakow wrote: > Am Fri, 22 Jan 2016 23:19:11 +0100 > schrieb "Armin K." <kre...@email.com>: > >> I use KDE Plasma 5 and lightdm as a display manager to login to the >> session. Once logged in, the lightdm (I guess it's using >> pam_systemd.so) login service will also start systemd user session >> and a session dbus daemon. The rest of Plasma follows. >> >> The problem is, that whenever I log out from Plasma, the systemd user >> session isn't terminated and as such leaves the user bus daemon and >> lots of services around, which makes shutdown hang (if I initiated >> the shutdown, which will first initiate log out) for some time (90 >> seconds by default until it's forcibly killed by systemd) which I >> rather find annoying. I can see the systemd user session is the >> culprit, because I can see "Waiting for session for user 1000 to >> terminate [timer]" or something like that. >> >> When I just log out, I can manually stop the systemd user session >> using loginctl kill-user/kill-session (I am not sure which one I used >> last time), which will terminate user bus and all the other services >> from that session. >> >> Now, to the original question: Once PAM closes the session (once >> logout is received), should systemd --user daemon terminate as well? >> Currently, that's not the case on my system. > > Which distribution do you use? Did you properly load the systemd bits > in pam? Usually, the systemd user session should end as soon as pam > closes the session - except there's still a process around (this is > probably why KillUserProcesses improved the situation). > This is Linux From Scratch, systemd is built by myself. See also my reply to your other mail. > My first guess is: Does your Xsession try to spawn dbus itself? Have you > tried commenting it out? Should be in /etc/X11 or somewhere in the > session files installed by lightdm. > There's only one dbus user daemon. I have no XSession (cough, lightdm, cough), and no files in /etc/X11 that start one. > My Xsession files look if there's already a dbus around (probably > provided by systemd user session) and only spawns one if there's none. > > If you identify the problematic process you could try to kill it using > KDE's shutdown scripts (look in "vi $(which startkde)" to see > where it looks for shutdown scripts). It'll be a workaround but may > help. > Again, see my other reply. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should pam-activated systemd --user daemon quit after session has been closed?
On 23.01.2016 00:37, Kai Krakow wrote: > Am Sat, 23 Jan 2016 00:20:34 +0100 > schrieb "Armin K." <kre...@email.com>: > >>> My first guess is: Does your Xsession try to spawn dbus itself? >>> Have you tried commenting it out? Should be in /etc/X11 or >>> somewhere in the session files installed by lightdm. >>> >> >> There's only one dbus user daemon. I have no XSession (cough, >> lightdm, cough), and no files in /etc/X11 that start one. > > Even lightdm uses session scripts. They are just not where you expect > them (read: not in /etc/X11). > > SDDM has them here: > /usr/share/sddm/scripts > > These even source some scripts from /etc/X11 (at least in Gentoo). > > I don't remember where lightdm stored those. > I don't have any distro scripts. Just the stock XSession file shipped by lightdm source tarball that should load bunch of files if they are available. I haven't got a single file that's referenced in XSession. Nothing else but systemd starts user bus (and that's not the real issue either, so I don't see what it has to do with all this) signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should pam-activated systemd --user daemon quit after session has been closed?
On 22.01.2016 23:19, Armin K. wrote: > Hi, > > I have a following problem on my system and it has been bothering me for some > time. > > I use KDE Plasma 5 and lightdm as a display manager to login to the session. > Once > logged in, the lightdm (I guess it's using pam_systemd.so) login service will > also > start systemd user session and a session dbus daemon. The rest of Plasma > follows. > > The problem is, that whenever I log out from Plasma, the systemd user session > isn't > terminated and as such leaves the user bus daemon and lots of services > around, which > makes shutdown hang (if I initiated the shutdown, which will first initiate > log out) > for some time (90 seconds by default until it's forcibly killed by systemd) > which > I rather find annoying. I can see the systemd user session is the culprit, > because > I can see "Waiting for session for user 1000 to terminate [timer]" or > something > like that. > > When I just log out, I can manually stop the systemd user session using > loginctl > kill-user/kill-session (I am not sure which one I used last time), which will > terminate > user bus and all the other services from that session. > > Now, to the original question: Once PAM closes the session (once logout is > received), > should systemd --user daemon terminate as well? Currently, that's not the > case on my > system. > > Let me know if I can provide any additional info. > > Cheers > And I'm not the only one who ran into this issue https://github.com/systemd/systemd/issues/1615 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] About github repo and release tarball change
On 09.07.2015 13:44, Kay Sievers wrote: On Thu, Jul 9, 2015 at 11:43 AM, Armin K. kre...@email.com wrote: I discovered a commit 2c8849add40805256156a36d7ef8c54cf019e29e by Kay Sievers which literally broke the make dist target. A lot of += were removed, making a target that appears more than once redefine itself each time instead of appending the new lines to an already existing target which made make dist ommit a few essential files in a tarball. Specifics please. Few essential files is a pretty useless information. Kay a is systemd-221 from fd.o, b is systemd-222 generated by make dist. TL;DR - files used to build the compat libs are missing even though --enable-compat libs was specified on ./configure line before make dist was built. Man pages and html docs were ommited from the list. Only in b: autogen.sh Only in b: CODING_STYLE Only in b: .dir-locals.el Only in a: libsystemd-daemon.c Only in a: libsystemd-id128.c Only in a: libsystemd-journal.c Only in a: libsystemd-login.c Only in b: .mailmap Only in b: README.md Only in b/shell-completion/zsh: _busctl Only in a/src/journal-remote: journal-remote.conf.in Only in a/src/libsystemd-terminal: unifont-glyph-array.bin Only in b/test: loopy2.service Only in b/test: loopy3.service Only in b/test: loopy4.service Only in b/test: loopy.service Only in b/test: loopy.service.d Only in b/test: Makefile Only in b/test: README.testsuite Only in b/test: splash.bmp Only in b/test: TEST-01-BASIC Only in b/test: TEST-02-CRYPTSETUP Only in b/test: TEST-03-JOBS Only in b/test: test-functions Only in a: test-libsystemd-sym.c Only in a: test-libudev-sym.c Only in b/tmpfiles.d: journal-nocow.conf Only in b/tools: make-man-rules.py Only in b: .travis.yml Only in a/units: systemd-journal-remote.service.in Only in b: .vimrc Only in b: .ycm_extra_conf.py -- Note: My last name is not Krejzi. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] About github repo and release tarball change
On 09.07.2015 14:17, Armin K. wrote: On 09.07.2015 13:44, Kay Sievers wrote: On Thu, Jul 9, 2015 at 11:43 AM, Armin K. kre...@email.com wrote: I discovered a commit 2c8849add40805256156a36d7ef8c54cf019e29e by Kay Sievers which literally broke the make dist target. A lot of += were removed, making a target that appears more than once redefine itself each time instead of appending the new lines to an already existing target which made make dist ommit a few essential files in a tarball. Specifics please. Few essential files is a pretty useless information. Kay a is systemd-221 from fd.o, b is systemd-222 generated by make dist. TL;DR - files used to build the compat libs are missing even though --enable-compat libs was specified on ./configure line before make dist was built. Man pages and html docs were ommited from the list. Scratch that. I just found out that the compat-libs source files are generated. Still, man pages and html docs issue exists. -- Note: My last name is not Krejzi. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] About github repo and release tarball change
Hello, I have been systemd user since version 38 and have followed the development ever since then. But, since the move to github, it has become extremely difficult to track commits via the web interface between releases now that pull requests are preferred method of contributing. I guess main reason for that is that the commit time is left as the original author commited it to his fork. That makes some patches way in the past on the web interface, which makes me (or more people) think the patch was there since, for example, 220 instead of post 221 release. Now, this might be an issue with my limited git knowledge, but I don't think that's related to the web interface not showing the commits in the correct order between two release tags. So, my first question is: How do I get around this? Is there any sane way of me knowing which exactly commits happened between two release tags from the web interface? If not, is there any other method for achieving the same (from the git tree itself). I am also a maintainer of Linux From Scratch systemd edition, which is a book that guides an user to utilize an existing Linux system to build a new, minimal one from sources, while teaching the user about core packages build procedures and how the Linux system is put together. Another goal is to apply as few patches as possible to get it to work properly. That said, we only link to upstream sources and let the user download, extract and run the commands required to configure, build and install the package. The distribution includes about 60 source packages, each in format that includes package name and package version in its tarball name. Now, to the problem. Starting with systemd-222, github tarballs are preferred and the downloaded tarball is in format v222.tar.gz, which is, due to what I said above, unnacceptable for the book to refecence. (Imagine everyone went the same path and provided tarballs with version in it - it would become a mess and impossible to distinguish between different source packages). I wasn't subscribed to the mailing list at the time notice was sent about using github-generated tarballs, so I couldn't speak up and I apologize for that. But, now that systemd-222 has been released, I have started looking at how to integrate the 222 release into Linux From Scratch systemd edition. The first idea was to download the unmodified tarball to our server and simply rename it to systemd-221.tar.gz and use that. The idea went down since the tarball doesn't include autotools generated files such as configure and Makefile.in. Due to minimalism of the distribution, to utilize ./autogen.sh on a Linux From Scratch system would require adding additional packages to the core distribution just for that sake, which is also unnaceptable (see the libgcrypt issue posted recently and I don't want to mention python). With that idea down the toilet, I went: wth, I can create a distribution tarball myself and host it the same way I'd host a renamed tarball and reference it from our book. I fired up configure, make dist and to my surprise, generated tarball contents didn't match ones available in the 221 tarball. I discovered a commit 2c8849add40805256156a36d7ef8c54cf019e29e by Kay Sievers which literally broke the make dist target. A lot of += were removed, making a target that appears more than once redefine itself each time instead of appending the new lines to an already existing target which made make dist ommit a few essential files in a tarball. Another major issue for our distribution is removal of generated man pages and html documents from the distribution tarball, which would leave our users without documentation on a default install, given that the distro itself (again, due to its minimalism) doesn't include the necessary tools to build them from source. Previously, even though those tools weren't present, the pre-generated man pages and html docs installed nicely. Third issue in the mentioned commit, although not important for us (and I doubt anyone in that matter) is inclusion of non-distribution related files in the tarball, such as autogen.sh, the various dotfiles, several developer-only related tools, etc. IMO, those shouldn't be part of a distro tarball (but as I said, it isn't an issue, just a random thought). And yes, I'm aware that the commit is there to sync the git archive and make dist targets, but it just breaks too much for too little gain - the git archive target generates more broken tarball and with more useless stuff than the actual make dist target. Now, that you know my story (I'm not sorry for the long post by the way), what do you advise me to do in the case of tarball distribution? Do I really have to maintain a patch to generate a non broken tarball from now on? -- Note: My last name is not Krejzi. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
Re: [systemd-devel] About github repo and release tarball change
On 09.07.2015 15:17, Martin Pitt wrote: Armin K. [2015-07-09 14:42 +0200]: Still, man pages and html docs issue exists. That's by design. They are built from the docbook sources. Martin Some new design? Previously, make dist would bundle the built sources into distribution tarball before the commit I mentioned in original post was done. Nonetheless, I've solved most of the issues I'd run into: I have to generate the tarball nonetheless to integrate into our distro. I can patch the makefile (partially revert the offending commit) to include man pages and html docs into that tarball. I suppose I'm not doing anything wrong/illegal as long as I describe the build procedure/provide the patch (or both)? -- Note: My last name is not Krejzi. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] About github repo and release tarball change
On 09.07.2015 12:32, Andrei Borzenkov wrote: On Thu, Jul 9, 2015 at 12:43 PM, Armin K. kre...@email.com wrote: So, my first question is: How do I get around this? Is there any sane way of me knowing which exactly commits happened between two release tags from the web interface? If not, is there any other method for achieving the same (from the git tree itself). I expect git log --no-merges v221..v222 to show the correct sequence. Does it not work for you? Yes, that's a lot saner than the web interface. Still, I'd prefer if that could be done via the web interface, so I could click on a commit that may interest me to inspect it further. For now, I'll be satisfied with this. Thanks. Starting with systemd-222, github tarballs are preferred and the downloaded tarball is in format v222.tar.gz, which is, due to what I said above, unnacceptable for the book to refecence. (Imagine everyone went the same path and provided tarballs with version in it - it would become a mess and impossible to distinguish between different source packages). I clicked on release link and it downloaded file with name systemd-222.tar.gz. I see that there could be an issue with dumb cli clients not following redirections probably. I suppose it's a github issue doing some black magic in the background. Still, even if the name was right, the github tarball doesn't suit my needs because it doesn't have autotools files and man pages/html docs. So, ignore this issue for my case ... -- Note: My last name is not Krejzi. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System locale not set in tty
On 03/25/2014 05:35 PM, Armin K. wrote: Hello there, I'm using stock systemd-211 release and I have noticed today that locale isn't set anymore in tty. My X session, which runs on tty1 has the locale correctly set up, but when I swich to tty2 and log in, the locale is set to POSIX, LANG isn't set at all. Is this expected behaviour or what? Do I still need shell scripts for parsing /etc/locale.conf and setting it like that in /etc/profile* scripts? $ locale -a bs_BA bs_BA.iso88592 bs_BA.utf8 C croatian en_US en_US.iso88591 en_US.utf8 hr_HR hr_HR.iso88592 hr_HR.utf8 hrvatski POSIX $ locale (from X11 terminal emulator) LANG=en_US.utf8 LC_CTYPE=en_US.utf8 LC_NUMERIC=en_US.utf8 LC_TIME=en_US.utf8 LC_COLLATE=en_US.utf8 LC_MONETARY=en_US.utf8 LC_MESSAGES=en_US.utf8 LC_PAPER=en_US.utf8 LC_NAME=en_US.utf8 LC_ADDRESS=en_US.utf8 LC_TELEPHONE=en_US.utf8 LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=en_US.utf8 LC_ALL= $ locale (from tty prompt) LANG= LC_CTYPE=POSIX LC_NUMERIC=POSIX LC_TIME=POSIX LC_COLLATE=POSIX LC_MONETARY=POSIX LC_MESSAGES=POSIX LC_PAPER=POSIX LC_NAME=POSIX LC_ADDRESS=POSIX LC_TELEPHONE=POSIX LC_MEASUREMENT=POSIX LC_IDENTIFICATION=POSIX LC_ALL= $ localectl System Locale: LANG=en_US.UTF-8 VC Keymap: croat X11 Layout: hr X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp Cheers. Anyone? -- Note: My last name is not Krejzi. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System locale not set in tty
On 04/10/2014 04:13 PM, Mike Gilbert wrote: On Thu, Apr 10, 2014 at 10:04 AM, Armin K. kre...@email.com wrote: On 03/25/2014 05:35 PM, Armin K. wrote: Hello there, I'm using stock systemd-211 release and I have noticed today that locale isn't set anymore in tty. My X session, which runs on tty1 has the locale correctly set up, but when I swich to tty2 and log in, the locale is set to POSIX, LANG isn't set at all. Is this expected behaviour or what? Do I still need shell scripts for parsing /etc/locale.conf and setting it like that in /etc/profile* scripts? This seems to have been intentional, though it occurred way before systemd-211. http://cgit.freedesktop.org/systemd/systemd/commit/?id=1640944a847249d3f5f0fb0d5a5f820a82efaed0 On Gentoo, we have the shell read the information from /etc/locale.conf. Hm, I don't recall having the problem before 210, but yea, removing the Environment line from getty@.service fixes my problems. Thanks. -- Note: My last name is not Krejzi. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-git Build failed
On 04/05/2014 02:00 PM, arnaud gaboury wrote:
I am running Archlinux with a custom 3.18.1 Kernel. Full system is upgraded.
Are you from the future? I doubt that networkd supports kernels from the
future :|
Usually systemd-git build fine using the AUR package[1]. The last two
builds(first one was with linux 3.17) with these errors:
***
src/libsystemd/sd-rtnl/rtnl-types.c:72:52: error: 'IFLA_BOND_MAX'
undeclared here (not in a function)
static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
^
src/libsystemd/sd-rtnl/rtnl-types.c:73:10: error: 'IFLA_BOND_MODE'
undeclared here (not in a function)
[IFLA_BOND_MODE]= { .type = NLA_U8 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: array index in
initializer not of integer type
[IFLA_BOND_MODE]= { .type = NLA_U8 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: (near initialization
for 'rtnl_link_info_data_bond_types')
src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: field name not in
record or union initializer
src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: (near initialization
for 'rtnl_link_info_data_bond_types')
src/libsystemd/sd-rtnl/rtnl-types.c:74:10: error:
'IFLA_BOND_ACTIVE_SLAVE' undeclared here (not in a function)
[IFLA_BOND_ACTIVE_SLAVE]= { .type = NLA_U32 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: array index in
initializer not of integer type
[IFLA_BOND_ACTIVE_SLAVE]= { .type = NLA_U32 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: (near initialization
for 'rtnl_link_info_data_bond_types')
src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: field name not in
record or union initializer
src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: (near initialization
for 'rtnl_link_info_data_bond_types')
src/libsystemd/sd-rtnl/rtnl-types.c:72:21: warning:
'rtnl_link_info_data_bond_types' defined but not used
[-Wunused-variable]
static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
^
Makefile:11868: recipe for target
'src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo' failed
./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs
--enable-kdbus --sysconfdir=/etc --localstatedir=/var
--libdir=/usr/lib --enable-gtk-doc
Am I missing something ? Did I disabled anything when building my
kernel which could be the root of this issue ?
TY for help.
Jokes aside.
If the 3.18 was a typo and if that's 3.8 kernel, then you might have
some trouble:
http://lists.freedesktop.org/archives/systemd-devel/2014-March/018347.html
But that's related to userspace headers, linux-api-headers.
[1]https://aur.archlinux.org/packages/systemd-git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Note: My last name is not Krejzi.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] System locale not set in tty
Hello there, I'm using stock systemd-211 release and I have noticed today that locale isn't set anymore in tty. My X session, which runs on tty1 has the locale correctly set up, but when I swich to tty2 and log in, the locale is set to POSIX, LANG isn't set at all. Is this expected behaviour or what? Do I still need shell scripts for parsing /etc/locale.conf and setting it like that in /etc/profile* scripts? $ locale -a bs_BA bs_BA.iso88592 bs_BA.utf8 C croatian en_US en_US.iso88591 en_US.utf8 hr_HR hr_HR.iso88592 hr_HR.utf8 hrvatski POSIX $ locale (from X11 terminal emulator) LANG=en_US.utf8 LC_CTYPE=en_US.utf8 LC_NUMERIC=en_US.utf8 LC_TIME=en_US.utf8 LC_COLLATE=en_US.utf8 LC_MONETARY=en_US.utf8 LC_MESSAGES=en_US.utf8 LC_PAPER=en_US.utf8 LC_NAME=en_US.utf8 LC_ADDRESS=en_US.utf8 LC_TELEPHONE=en_US.utf8 LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=en_US.utf8 LC_ALL= $ locale (from tty prompt) LANG= LC_CTYPE=POSIX LC_NUMERIC=POSIX LC_TIME=POSIX LC_COLLATE=POSIX LC_MONETARY=POSIX LC_MESSAGES=POSIX LC_PAPER=POSIX LC_NAME=POSIX LC_ADDRESS=POSIX LC_TELEPHONE=POSIX LC_MEASUREMENT=POSIX LC_IDENTIFICATION=POSIX LC_ALL= $ localectl System Locale: LANG=en_US.UTF-8 VC Keymap: croat X11 Layout: hr X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp Cheers. -- Note: My last name is not Krejzi. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: Don't distribute generated udev rule
On 03/04/2014 04:23 PM, Armin K wrote: It contains hardcoded path to systemd-sysctl executable which is /usr/lib/systemd/systemd-sysctl on latest stable release and as such it will complain at runtime if rootprefix != prefix --- Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 251b5d0..352381c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2568,7 +2568,6 @@ dist_network_DATA = \ network/80-container-host0.network dist_udevrules_DATA += \ - rules/99-systemd.rules \ rules/42-usb-hid-pm.rules \ rules/50-udev-default.rules \ rules/60-drm.rules \ Ping? -- Note: My last name is not Krejzi. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: Don't distribute generated udev rule
It contains hardcoded path to systemd-sysctl executable which is /usr/lib/systemd/systemd-sysctl on latest stable release and as such it will complain at runtime if rootprefix != prefix --- Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 251b5d0..352381c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2568,7 +2568,6 @@ dist_network_DATA = \ network/80-container-host0.network dist_udevrules_DATA += \ - rules/99-systemd.rules \ rules/42-usb-hid-pm.rules \ rules/50-udev-default.rules \ rules/60-drm.rules \ -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: Do not distribute generated udev service files
They are already in nodist_systemunit_DATA and if they are shipped, they contain hardcoded paths to udevadm and systemd-udevd which will cause them to fail to start when rootprefix != prefix and rootlibdir != libdir. --- Makefile.am | 3 --- 1 file changed, 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index dd067f6..e51bca0 100644 --- a/Makefile.am +++ b/Makefile.am @@ -502,9 +502,6 @@ EXTRA_DIST += \ units/systemd-f...@.service.in \ units/systemd-fsck-root.service.in \ units/u...@.service.in \ - units/systemd-udevd.service \ - units/systemd-udev-trigger.service \ - units/systemd-udev-settle.service \ units/debug-shell.service.in \ units/systemd-hibernate.service.in \ units/systemd-hybrid-sleep.service.in \ -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] build-sys: Also move libsystemd-journal to rootlibdir
--- Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile.am b/Makefile.am index e25d532..b1f0670 100644 --- a/Makefile.am +++ b/Makefile.am @@ -4479,11 +4479,13 @@ lib_LTLIBRARIES += \ # move lib from $(libdir) to $(rootlibdir) and update devel link, if needed compat-lib-install-hook: libname=libsystemd-login.so $(move-to-rootlibdir) + libname=libsystemd-journal.so $(move-to-rootlibdir) libname=libsystemd-id128.so $(move-to-rootlibdir) libname=libsystemd-daemon.so $(move-to-rootlibdir) compat-lib-uninstall-hook: rm -f $(DESTDIR)$(rootlibdir)/libsystemd-login.so* + rm -f $(DESTDIR)$(rootlibdir)/libsystemd-journal.so* rm -f $(DESTDIR)$(rootlibdir)/libsystemd-id128.so* rm -f $(DESTDIR)$(rootlibdir)/libsystemd-daemon.so* -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] build-sys: Also move libsystemd-journal to rootlibdir
On 02/22/2014 05:44 PM, Kay Sievers wrote:
On Sat, Feb 22, 2014 at 3:22 PM, Armin K kre...@email.com wrote:
---
Makefile.am | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Makefile.am b/Makefile.am
index e25d532..b1f0670 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4479,11 +4479,13 @@ lib_LTLIBRARIES += \
# move lib from $(libdir) to $(rootlibdir) and update devel link, if needed
compat-lib-install-hook:
libname=libsystemd-login.so $(move-to-rootlibdir)
+ libname=libsystemd-journal.so $(move-to-rootlibdir)
libname=libsystemd-id128.so $(move-to-rootlibdir)
libname=libsystemd-daemon.so $(move-to-rootlibdir)
Hmm, that is already in the libsystemd section and does not belong in
the compat libs section.
Please check does not work for you?
Kay
When --enable-compat-libs is used, and rootlibdir != libdir,
libsystemd-{login,id128,daemon}.so.* (versioned libraries) get installed
in rootlibdir, but libsystemd-daemon.so.* remains in libdir. Either
don't move any or move them all, simple as that.
--
Note: My last name is not Krejzi.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot boot after upgrading to latest git version
On 02/22/2014 05:18 PM, Dave Reisner wrote: On Sat, Feb 22, 2014 at 04:05:31PM +0100, Armin K. wrote: Hi, I just finished upgrading to latest git master and I can't boot anymore. Without knowing what version you upgraded *from*, this is incomplete information. Sorry, I was using version 208, tarball from fd.o, no additional patches. Partitions are failing to mount, even though I can confirm that correct device nodes exist in /dev when I enter the rescue mode shell. I don't use initramfs on this system, so all drivers are mostly built into kernel and devtmpfs is mounted even before systemd is started, so at least /dev/sda7 should be detected, but it isn't as you can see. Attached is the journalctl -xb log from rescue console. There's been a number posts like this on the list recently, all of which point to the kernel not having CONFIG_FHANDLE=y. Indeed, I don't have CONFIG_FHANDLE set in my kernel. I didn't notice it before though, and changelog didn't mention it like it did compat-libs and kdbus. Oh well, it's my mistake for not reading README again. Rebuilding kernel now, I'll complain again if something breaks. Thanks. -- Note: My last name is not Krejzi. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Udev rule question
Hello,
we have been using Udev without systemd (currently tracking version 205)
and we have a problem. The rule that worked some time ago (can't
remember when) doesn't work anymore.
It's alsa-utils rule for restoring the volume at boot using Udev rule.
This is the current rule which doesn't work:
ACTION==add, SUBSYSTEM==sound, KERNEL==controlC*,
KERNELS!=card*, GOTO=alsa_restore_go
GOTO=alsa_restore_end
LABEL=alsa_restore_go
TEST!=/etc/alsa/state-daemon.conf, RUN+=/usr/sbin/alsactl restore
$attr{number}
TEST==/etc/alsa/state-daemon.conf, RUN+=/usr/sbin/alsactl nrestore
$attr{number}
LABEL=alsa_restore_end
The rule was changed in 1.0.27 release. Before 1.0.27 release it was
like this:
ACTION==add, SUBSYSTEM==sound, KERNEL==controlC*, KERNELS==card*, \
RUN+=/usr/sbin/alsactl restore $attr{number}
Unfortunately, none of these work anymore. I don't know if something is
wrong with rules. If so, please say what and I'll report it to upstream.
Also, I presume that driver is built in into kernel, but similar rule
for rtc clock saving/restoring is working fine with rtc driver builtin.
And no, systemd+udev is not an option (I've tried my best, sorry).
Everything else appears to work.
Looking forward to any advice. Thanks in advance.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [206] Randomly on shutdown, stop timeout for user@.service
On 24.7.2013 20:50, Cristian Rodríguez wrote: El 24/07/13 14:07, Gerardo Exequiel Pozzi escribió: Hello I am using Arch Linux, and testing systemd-206 with linux-3.10.2 on shutdown, sometimes randomly there is a long delay until user@0.service timeouts then systemd kills it. I am seeing a similar behaviour here, but it hangs shutting down the session-1.scope unit. I have been seeing the same behaviour for a long time (since 19x releases). It hangs for about a minute before shutting down. I never narrowed which unit hangs. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging systemd shutdown problem on openSuSE 12.3
On 05/13/2013 04:05 PM, Zbigniew Jędrzejewski-Szmek wrote: On Mon, May 13, 2013 at 03:50:41PM +0200, Rainer Krienke wrote: I waited at least 5 minutes one time even an hour. It seems most processes are beeing killed however something hangs. My guess was that perhaps autofs is not terminated correctly which might cause hanging NFS mounts, but this is only a guess because I cannot see what happens inside systemd. Thats why I look for ways to find out more. There've been a number of fixes in this area since systemd-195. Most notably http://cgit.freedesktop.org/systemd/systemd/commit/?id=aaf7eb8. Would be great if you could try with a recent version. Zbyszek I don't even use autofs, have no network systems mounted and I use Systemd 204, but I still get nearly the same behaviour - although I can confirm that system shuts down (or hangs at Power Down - ACPI bug) after minute or two of waiting. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On 06/19/2012 08:00 PM, Jürgen Daubert wrote: Kay Sievers kay at vrfy.org writes: [...] We said udev *runs* alone, not that you can tweak the build system to only build it. And that is still all true. Sorry, but in your first announcement [1] this sounds quite different to me. At all I got the impression that the whole merge is more or less a try to force pepole to use systemd. Heh, looks like so. regards Juergen [1] http://article.gmane.org/gmane.linux.hotplug.devel/17392 I guess you are talking about this part? *Distributions not wishing to adopt systemd can build udev pretty much the same way as before, however should then use the systemd tarball instead of the udev tarball and package only what is necessary of the resulting build.* But it looks like this one can be interpreted in two ways: Build udev same way as before (with same deps) or build udev same way as before (same procedure). I think most of you minimalists interpreted that as the first one. But also, it isn't really fair not to allow user to choose what to build. I have nothing against systemd in LFS and source based distros. I even use it in my LFS setup, it is far more better than the sysvinit and those bash init scripts. But if you look arround, people will always mock about too much dependencies even tough those don't use anything on todays hardware. Just let them choose wether they want to BUILD (not RUN) systemd and do not force them in any way (and sorry for saying this, but this behaviour looks just like you want to force everyone to build/use systemd even if they won't), it isn't in the spirit of Free and Open Source Software. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
