Re: [systemd-devel] [ANNOUNCE] systemd v221
2015-06-19 16:11 GMT+02:00 Michael Biebl mbi...@gmail.com: I'm very disappointed (once again) how this release was handled. Lot's of last minute changes. Especially https://github.com/systemd/systemd/pull/293 really sucks. While I'm still disappointed how this issue was handled and I still find the arguments for this pull request rather unconvincing, my reaction was not ok either. I apologize for that. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v221
Kay Sievers wrote on 20/06/15 20:49: On Sat, Jun 20, 2015 at 6:08 PM, cee1 fykc...@gmail.com wrote: 2015-06-20 2:06 GMT+08:00 Lennart Poettering lenn...@poettering.net: On Fri, 19.06.15 16:06, Lennart Poettering (lenn...@poettering.net) wrote: Heya! It's primarily a bugfix release, but we also make sd-bus.h and sd-event.h public. (A blog story on sd-bus and how to use it will follow shortly.) The blog story is online now: http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html Enjoy, Glad to see this :) BTW, what about libabc? Would libsystemd be part of libabc? Also libsystemd is a linux-specific library, will it further ports and integrates some kernel libraries to libabc?? Assuming you mean this: https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git Libabac is an example stub that does absolutely nothing, and in the future it will keep doing nothing. Excellent. I'd hate to see a libabc API breakage ;) 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] [ANNOUNCE] systemd v221
2015-06-20 2:06 GMT+08:00 Lennart Poettering lenn...@poettering.net: On Fri, 19.06.15 16:06, Lennart Poettering (lenn...@poettering.net) wrote: Heya! It's primarily a bugfix release, but we also make sd-bus.h and sd-event.h public. (A blog story on sd-bus and how to use it will follow shortly.) The blog story is online now: http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html Enjoy, Glad to see this :) BTW, what about libabc? Would libsystemd be part of libabc? Also libsystemd is a linux-specific library, will it further ports and integrates some kernel libraries to libabc?? -- Regards, - cee1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v221
On Sat, Jun 20, 2015 at 6:08 PM, cee1 fykc...@gmail.com wrote: 2015-06-20 2:06 GMT+08:00 Lennart Poettering lenn...@poettering.net: On Fri, 19.06.15 16:06, Lennart Poettering (lenn...@poettering.net) wrote: Heya! It's primarily a bugfix release, but we also make sd-bus.h and sd-event.h public. (A blog story on sd-bus and how to use it will follow shortly.) The blog story is online now: http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html Enjoy, Glad to see this :) BTW, what about libabc? Would libsystemd be part of libabc? Also libsystemd is a linux-specific library, will it further ports and integrates some kernel libraries to libabc?? Assuming you mean this: https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git Libabac is an example stub that does absolutely nothing, and in the future it will keep doing nothing. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v221
I'm very disappointed (once again) how this release was handled. Lot's of last minute changes. Especially https://github.com/systemd/systemd/pull/293 really sucks. Not amused, not amused at all. 2015-06-19 16:06 GMT+02:00 Lennart Poettering lenn...@poettering.net: Heya! It's primarily a bugfix release, but we also make sd-bus.h and sd-event.h public. (A blog story on sd-bus and how to use it will follow shortly.) http://www.freedesktop.org/software/systemd/systemd-221.tar.xz Reminder: Note again that the git repository and bug tracking moved to github with this release. The new github page is this: https://github.com/systemd/systemd Reporting bugs via the fdo bugzilla is closed now. Changes to existing bugs can still be made, and discussion should continue there, but no new ones may be filed. We will not migrate individual bug reports from fdo to github. File new bugs as github issues, please. Please submit new patches preferable as github PRs now, however we will continue to accept patches via the ML, too. If you have a git checkout, don't forget to migrate to the new github GIT repository as origin: https://github.com/systemd/systemd.git The fdo git repo still exists though and is sporadically synced from the github repository. CHANGES WITH 221: * The sd-bus.h and sd-event.h APIs have now been declared stable and have been added to the official interface of libsystemd.so. sd-bus implements an alternative D-Bus client library, that is relatively easy to use, very efficient and supports both classic D-Bus as well as kdbus as transport backend. sd-event is a generic event loop abstraction that is built around Linux epoll, but adds features such as event prioritization or efficient timer handling. Both APIs are good choices for C programs looking for a bus and/or event loop implementation that is minimal and does not have to be portable to other kernels. * kdbus support is no longer compile-time optional. It is now always built-in. However, it can still be disabled at runtime using the kdbus=0 kernel command line setting, and that setting may be changed to default to off, by specifying --disable-kdbus at build-time. Note though that the kernel command line setting has no effect if the kdbus.ko kernel module is not installed, in which case kdbus is (obviously) also disabled. We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled. * The minimal required util-linux version has been bumped to 2.26. * Support for chkconfig (--enable-chkconfig) was removed in favor of calling an abstraction tool /lib/systemd/systemd-sysv-install. This needs to be implemented for your distribution. See SYSV INIT.D SCRIPTS in README for details. * If there's a systemd unit and a SysV init script for the same service name, and the user executes systemctl enable for it (or a related call), then this will now enable both (or execute the related operation on both), not just the unit. * The libudev API documentation has been converted from gtkdoc into man pages. * gudev has been removed from the systemd tree, it is now an external project. * The systemd-cgtop tool learnt a new --raw switch to generate raw (machine parsable) output. * networkd's IPForwarding= .network file setting learnt the new setting kernel, which ensures that networkd does not change the IP forwarding sysctl from the default kernel state. * The systemd-logind bus API now exposes a new boolean property Docked that reports whether logind considers the system docked, i.e. connected to a docking station or not. Contributions from: Alex Crawford, Andreas Pokorny, Andrei Borzenkov, Charles Duffy, Colin Guthrie, Cristian Rodríguez, Daniele Medri, Daniel Hahler, Daniel Mack, David Herrmann, David Mohr, Dimitri John Ledkov, Djalal Harouni, dslul, Ed Swierk, Eric Cook, Filipe Brandenburger, Gianpaolo Macario, Harald Hoyer, Iago López Galeiras, Igor Vuk, Jan Synacek, Jason Pleau, Jason S. McMullan, Jean Delvare, Jeff Huang, Jonathan Boulle, Karel Zak, Kay Sievers, kloun, Lennart Poettering, Marc-Antoine Perennou, Marcel Holtmann, Mario Limonciello, Martin Pitt, Michael Biebl, Michael Olbrich, Michal Schmidt, Mike Gilbert, Nick Owens, Pablo Lezaeta Reyes, Patrick Donnelly, Pavel Odvody, Peter Hutterer, Philip
Re: [systemd-devel] [ANNOUNCE] systemd v221
All this talk about getting downstream patches upstream and then last minute reverts without a proper justitification. WTF. 2015-06-19 16:11 GMT+02:00 Michael Biebl mbi...@gmail.com: I'm very disappointed (once again) how this release was handled. Lot's of last minute changes. Especially https://github.com/systemd/systemd/pull/293 really sucks. Not amused, not amused at all. 2015-06-19 16:06 GMT+02:00 Lennart Poettering lenn...@poettering.net: Heya! It's primarily a bugfix release, but we also make sd-bus.h and sd-event.h public. (A blog story on sd-bus and how to use it will follow shortly.) http://www.freedesktop.org/software/systemd/systemd-221.tar.xz Reminder: Note again that the git repository and bug tracking moved to github with this release. The new github page is this: https://github.com/systemd/systemd Reporting bugs via the fdo bugzilla is closed now. Changes to existing bugs can still be made, and discussion should continue there, but no new ones may be filed. We will not migrate individual bug reports from fdo to github. File new bugs as github issues, please. Please submit new patches preferable as github PRs now, however we will continue to accept patches via the ML, too. If you have a git checkout, don't forget to migrate to the new github GIT repository as origin: https://github.com/systemd/systemd.git The fdo git repo still exists though and is sporadically synced from the github repository. CHANGES WITH 221: * The sd-bus.h and sd-event.h APIs have now been declared stable and have been added to the official interface of libsystemd.so. sd-bus implements an alternative D-Bus client library, that is relatively easy to use, very efficient and supports both classic D-Bus as well as kdbus as transport backend. sd-event is a generic event loop abstraction that is built around Linux epoll, but adds features such as event prioritization or efficient timer handling. Both APIs are good choices for C programs looking for a bus and/or event loop implementation that is minimal and does not have to be portable to other kernels. * kdbus support is no longer compile-time optional. It is now always built-in. However, it can still be disabled at runtime using the kdbus=0 kernel command line setting, and that setting may be changed to default to off, by specifying --disable-kdbus at build-time. Note though that the kernel command line setting has no effect if the kdbus.ko kernel module is not installed, in which case kdbus is (obviously) also disabled. We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled. * The minimal required util-linux version has been bumped to 2.26. * Support for chkconfig (--enable-chkconfig) was removed in favor of calling an abstraction tool /lib/systemd/systemd-sysv-install. This needs to be implemented for your distribution. See SYSV INIT.D SCRIPTS in README for details. * If there's a systemd unit and a SysV init script for the same service name, and the user executes systemctl enable for it (or a related call), then this will now enable both (or execute the related operation on both), not just the unit. * The libudev API documentation has been converted from gtkdoc into man pages. * gudev has been removed from the systemd tree, it is now an external project. * The systemd-cgtop tool learnt a new --raw switch to generate raw (machine parsable) output. * networkd's IPForwarding= .network file setting learnt the new setting kernel, which ensures that networkd does not change the IP forwarding sysctl from the default kernel state. * The systemd-logind bus API now exposes a new boolean property Docked that reports whether logind considers the system docked, i.e. connected to a docking station or not. Contributions from: Alex Crawford, Andreas Pokorny, Andrei Borzenkov, Charles Duffy, Colin Guthrie, Cristian Rodríguez, Daniele Medri, Daniel Hahler, Daniel Mack, David Herrmann, David Mohr, Dimitri John Ledkov, Djalal Harouni, dslul, Ed Swierk, Eric Cook, Filipe Brandenburger, Gianpaolo Macario, Harald Hoyer, Iago López Galeiras, Igor Vuk, Jan Synacek, Jason Pleau, Jason S. McMullan, Jean Delvare, Jeff Huang, Jonathan Boulle, Karel Zak, Kay Sievers, kloun, Lennart Poettering, Marc-Antoine Perennou, Marcel Holtmann, Mario
Re: [systemd-devel] [ANNOUNCE] systemd v221
On Fri, 19.06.15 16:11, Michael Biebl (mbi...@gmail.com) wrote: I'm very disappointed (once again) how this release was handled. Lot's of last minute changes. I disagree. We only made bugfixes in the last days, except maybe one patch (that came with a lot of unit tests). That's how this works: we fix things we need to fix before we do a release. Also, due to the nice CI hookup we have now pretty much all patches are pretty extensively tested individually before we merge them. Especially https://github.com/systemd/systemd/pull/293 really sucks. If something is not in shape we'll revert it. Regardless of the general merits of the patch set: this one actually broke stuff, it was incomplete. Either you make the man pages dynamic, or you ship them pre-built. The patch set did both. That's broken, and hence has no place in a release. And I'd much rather see that stuff removed again than having to delay the release further. Not amused, not amused at all. I am sorry you feel that way. I am not sure though what you suggest: delay releases until zero bugfixes have been applied for a week? Well, that would mean we'd never do releases again, sorry. We have to release some time. On monday I announced that I'll do a release today, there was ample time to test things, and we found a number of issues that way and fixed them as they came along. Since yesterday night there wasn't anything release-critical open anymore, so I slept one night and did the release today since nothing of importance popped up in the meantime. 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] [ANNOUNCE] systemd v221
On Fri, 19.06.15 16:21, Michael Biebl (mbi...@gmail.com) wrote: All this talk about getting downstream patches upstream and then last minute reverts without a proper justitification. WTF. reverts? Plural? Which ones are you referring to excluding that man page path thing? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd v221
Heya! It's primarily a bugfix release, but we also make sd-bus.h and sd-event.h public. (A blog story on sd-bus and how to use it will follow shortly.) http://www.freedesktop.org/software/systemd/systemd-221.tar.xz Reminder: Note again that the git repository and bug tracking moved to github with this release. The new github page is this: https://github.com/systemd/systemd Reporting bugs via the fdo bugzilla is closed now. Changes to existing bugs can still be made, and discussion should continue there, but no new ones may be filed. We will not migrate individual bug reports from fdo to github. File new bugs as github issues, please. Please submit new patches preferable as github PRs now, however we will continue to accept patches via the ML, too. If you have a git checkout, don't forget to migrate to the new github GIT repository as origin: https://github.com/systemd/systemd.git The fdo git repo still exists though and is sporadically synced from the github repository. CHANGES WITH 221: * The sd-bus.h and sd-event.h APIs have now been declared stable and have been added to the official interface of libsystemd.so. sd-bus implements an alternative D-Bus client library, that is relatively easy to use, very efficient and supports both classic D-Bus as well as kdbus as transport backend. sd-event is a generic event loop abstraction that is built around Linux epoll, but adds features such as event prioritization or efficient timer handling. Both APIs are good choices for C programs looking for a bus and/or event loop implementation that is minimal and does not have to be portable to other kernels. * kdbus support is no longer compile-time optional. It is now always built-in. However, it can still be disabled at runtime using the kdbus=0 kernel command line setting, and that setting may be changed to default to off, by specifying --disable-kdbus at build-time. Note though that the kernel command line setting has no effect if the kdbus.ko kernel module is not installed, in which case kdbus is (obviously) also disabled. We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled. * The minimal required util-linux version has been bumped to 2.26. * Support for chkconfig (--enable-chkconfig) was removed in favor of calling an abstraction tool /lib/systemd/systemd-sysv-install. This needs to be implemented for your distribution. See SYSV INIT.D SCRIPTS in README for details. * If there's a systemd unit and a SysV init script for the same service name, and the user executes systemctl enable for it (or a related call), then this will now enable both (or execute the related operation on both), not just the unit. * The libudev API documentation has been converted from gtkdoc into man pages. * gudev has been removed from the systemd tree, it is now an external project. * The systemd-cgtop tool learnt a new --raw switch to generate raw (machine parsable) output. * networkd's IPForwarding= .network file setting learnt the new setting kernel, which ensures that networkd does not change the IP forwarding sysctl from the default kernel state. * The systemd-logind bus API now exposes a new boolean property Docked that reports whether logind considers the system docked, i.e. connected to a docking station or not. Contributions from: Alex Crawford, Andreas Pokorny, Andrei Borzenkov, Charles Duffy, Colin Guthrie, Cristian Rodríguez, Daniele Medri, Daniel Hahler, Daniel Mack, David Herrmann, David Mohr, Dimitri John Ledkov, Djalal Harouni, dslul, Ed Swierk, Eric Cook, Filipe Brandenburger, Gianpaolo Macario, Harald Hoyer, Iago López Galeiras, Igor Vuk, Jan Synacek, Jason Pleau, Jason S. McMullan, Jean Delvare, Jeff Huang, Jonathan Boulle, Karel Zak, Kay Sievers, kloun, Lennart Poettering, Marc-Antoine Perennou, Marcel Holtmann, Mario Limonciello, Martin Pitt, Michael Biebl, Michael Olbrich, Michal Schmidt, Mike Gilbert, Nick Owens, Pablo Lezaeta Reyes, Patrick Donnelly, Pavel Odvody, Peter Hutterer, Philip Withnall, Ronny Chevalier, Simon McVittie, Susant Sahani, Thomas Hindoe Paaboel Andersen, Tom Gundersen, Torstein Husebø, Umut Tezduyar Lindskog, Viktar Vauchkevich, Werner Fink, Zbigniew Jędrzejewski-Szmek -- Berlin, 2015-06-19 Lennart -- Lennart Poettering, Red Hat
Re: [systemd-devel] [ANNOUNCE] systemd v221
Am 19.06.2015 um 16:32 schrieb Lennart Poettering: On Fri, 19.06.15 16:15, Reindl Harald (h.rei...@thelounge.net) wrote: Am 19.06.2015 um 16:06 schrieb Lennart Poettering: * If there's a systemd unit and a SysV init script for the same service name, and the user executes systemctl enable for it (or a related call), then this will now enable both (or execute the related operation on both), not just the unit. that is an horrible regression in context of someone has written a systemd-unit for commercial software which only ships a sysv-init-script like vmware as example How so? the native unit always overrides the sysv init script. Hence the fact that the init script is enabled shouldn't really matter. then all is fine, the text above is not clear about that and now will enable both implies start both We did this to be nice to Debian, so that they can support booting into sysvinit in parallel to systemd, so that the enable status is kept in sync between systemd and sysvinit the text above is just misleading 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] [ANNOUNCE] systemd v221
Guys let's try to be constructive here... This time it shouldn't be too painful for downstreams since the revert was the last patch to the man subtree so just a git revert of that should get your trees to the state you need to get v221 packages for Debian and Ubuntu. In that sense, I think we're still (slightly) better off than we were in v220 and I think we have all we need to solve this one for good in v222. And let's use the momentum to try to solve this soon, in which case you could even replace the revert of that commit with the backport of the next one (which will probably remove the disted manpages). Cheers, Filipe On Fri, Jun 19, 2015 at 7:40 AM, Michael Biebl mbi...@gmail.com wrote: 2015-06-19 16:38 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Fri, 19.06.15 16:29, Michael Biebl (mbi...@gmail.com) wrote: If something is not in shape we'll revert it. Regardless of the general merits of the patch set: this one actually broke stuff, it was incomplete. Either you make the man pages dynamic, or you ship them pre-built. The patch set did both. That's broken, and hence has no place in a release. And I'd much rather see that stuff removed again than having to delay the release further. Not amused, not amused at all. I am sorry you feel that way. I am not sure though what you suggest: delay releases until zero bugfixes have been applied for a week? Well, that would mean we'd never do releases again, sorry. We have to release some time. On Bullshit. That's been in master for a while and the justification for reverting appear to totally made up. I wasn't the one who reverted it or even involved in the discussions. But what I saw is that the patch was borked, since it one one hand tried to ship the man pages pre-built but also wanted to make them different depending on ./configure runs. And that's just *broken*. The justification for the revert basically boil down to: let's make it as hard as possible and use systemd as a stick to force them to not use split-usr. The arguments for the for the patch being broken are completely made up. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v221
On Fri, 19.06.15 16:15, Reindl Harald (h.rei...@thelounge.net) wrote: Am 19.06.2015 um 16:06 schrieb Lennart Poettering: * If there's a systemd unit and a SysV init script for the same service name, and the user executes systemctl enable for it (or a related call), then this will now enable both (or execute the related operation on both), not just the unit. that is an horrible regression in context of someone has written a systemd-unit for commercial software which only ships a sysv-init-script like vmware as example How so? the native unit always overrides the sysv init script. Hence the fact that the init script is enabled shouldn't really matter. We did this to be nice to Debian, so that they can support booting into sysvinit in parallel to systemd, so that the enable status is kept in sync between systemd and sysvinit. 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] [ANNOUNCE] systemd v221
Am 19.06.2015 um 16:06 schrieb Lennart Poettering: * If there's a systemd unit and a SysV init script for the same service name, and the user executes systemctl enable for it (or a related call), then this will now enable both (or execute the related operation on both), not just the unit. that is an horrible regression in context of someone has written a systemd-unit for commercial software which only ships a sysv-init-script like vmware as example 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] [ANNOUNCE] systemd v221
В Fri, 19 Jun 2015 16:15:03 +0200 Reindl Harald h.rei...@thelounge.net пишет: Am 19.06.2015 um 16:06 schrieb Lennart Poettering: * If there's a systemd unit and a SysV init script for the same service name, and the user executes systemctl enable for it (or a related call), then this will now enable both (or execute the related operation on both), not just the unit. that is an horrible regression in context of someone has written a systemd-unit for commercial software which only ships a sysv-init-script like vmware as example Why? If native unit is present it will screen initscript anyway. But this change ensures that both systemd and sysvinit will see the same state for similar named services. pgpFFsZbxNYGe.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v221
2015-06-19 16:38 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Fri, 19.06.15 16:29, Michael Biebl (mbi...@gmail.com) wrote: If something is not in shape we'll revert it. Regardless of the general merits of the patch set: this one actually broke stuff, it was incomplete. Either you make the man pages dynamic, or you ship them pre-built. The patch set did both. That's broken, and hence has no place in a release. And I'd much rather see that stuff removed again than having to delay the release further. Not amused, not amused at all. I am sorry you feel that way. I am not sure though what you suggest: delay releases until zero bugfixes have been applied for a week? Well, that would mean we'd never do releases again, sorry. We have to release some time. On Bullshit. That's been in master for a while and the justification for reverting appear to totally made up. I wasn't the one who reverted it or even involved in the discussions. But what I saw is that the patch was borked, since it one one hand tried to ship the man pages pre-built but also wanted to make them different depending on ./configure runs. And that's just *broken*. The justification for the revert basically boil down to: let's make it as hard as possible and use systemd as a stick to force them to not use split-usr. The arguments for the for the patch being broken are completely made up. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v221
On Fri, 19.06.15 16:40, Michael Biebl (mbi...@gmail.com) wrote: 2015-06-19 16:38 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Fri, 19.06.15 16:29, Michael Biebl (mbi...@gmail.com) wrote: If something is not in shape we'll revert it. Regardless of the general merits of the patch set: this one actually broke stuff, it was incomplete. Either you make the man pages dynamic, or you ship them pre-built. The patch set did both. That's broken, and hence has no place in a release. And I'd much rather see that stuff removed again than having to delay the release further. Not amused, not amused at all. I am sorry you feel that way. I am not sure though what you suggest: delay releases until zero bugfixes have been applied for a week? Well, that would mean we'd never do releases again, sorry. We have to release some time. On Bullshit. That's been in master for a while and the justification for reverting appear to totally made up. I wasn't the one who reverted it or even involved in the discussions. But what I saw is that the patch was borked, since it one one hand tried to ship the man pages pre-built but also wanted to make them different depending on ./configure runs. And that's just *broken*. The justification for the revert basically boil down to: let's make it as hard as possible and use systemd as a stick to force them to not use split-usr. Well, to make that clear, we support split-usr for compatibility reasons, to be nice to debian and ubuntu. But we don't like the concept, and we'll not compromise for it. For example, ProtectSystem= isn't really effective with split-usr either. Neither does nspawn's --volatile= switch or anything else related to the stateless/factory reset stuff we are working on work with it. Also, when it comes to file search paths I am strongly of the opinion that we never should document the paths in the root dir, since they generally are a form of API: it's an extension point for 3rd party packages, and we should communicate clearly where that point is and that it is always the same. If we instead say it can be anything, depending on your distro, then we aren't better than sysvinit. So yes, the split-usr thing is unloved by many of the systemd upstream devs. We'll continue to support it though, but only the minimal level necessary to make things work and not regress. And: the quirks it causes we'll not necessarily document, simply because we want the man pages clear and clean and not contain a list of compat quirks that apply to some systems only. The above is my personal opinion, and again in the specific decision and discussion about the reverted man patches I was not involved. And as far as I can see the communication around it wasn't very good. I am very sorry for that, we should do this better, 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] [ANNOUNCE] systemd v221
On Fri, Jun 19, 2015 at 5:07 PM, Filipe Brandenburger filbran...@google.com wrote: Guys let's try to be constructive here... This time it shouldn't be too painful for downstreams since the revert was the last patch to the man subtree so just a git revert of that should get your trees to the state you need to get v221 packages for Debian and Ubuntu. In that sense, I think we're still (slightly) better off than we were in v220 and I think we have all we need to solve this one for good in v222. And let's use the momentum to try to solve this soon, in which case you could even replace the revert of that commit with the backport of the next one (which will probably remove the disted manpages). I was involved in the decision to revert it. And I'm sure we should not add the patch back. The split-usr option is not much more than an upgrade path for traditional unix layouts to merge the operating system into a single directory. The split-usr option is nothing upstream systemd could fully suport. We need the unified layout for several options systemd offers, and more and more new things will rely on it. Split-usr will not got away anytime soon, but it will get less and less support regarding new features we add to systemd. The last-minute revert was not properly communicated, I am sorry for that, but the technical reasons for the revert are still true. Not dist'ing the man pages does not make the feature itself correct. We should not provide options to render the man page content inconsistently. The search paths would need to be mangled too, or none of them. But again, I am against upstream support for man split-usr man pages because systemd cannot fully support split-usr anyway, and should not pretend it does. Please do that downstream where the classic file system layout is supported. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v221
On Fri, 19.06.15 16:06, Lennart Poettering (lenn...@poettering.net) wrote: Heya! It's primarily a bugfix release, but we also make sd-bus.h and sd-event.h public. (A blog story on sd-bus and how to use it will follow shortly.) The blog story is online now: http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html Enjoy, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
