Re: Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 05/25/2013 02:53 PM, Anthony G. Basile wrote: On 05/25/2013 02:13 PM, Markos Chandras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/25/2013 05:14 PM, Ben de Groot wrote: But if a co-maintainer pushes through a change that I oppose, then working together becomes quite difficult. In this case I opted to give up maintainership. Ben, We've been working together, in the same team(s), for more than 4 years and we never had a single problem in co-maintaining packages. I would never expected you to make so much noise because I committed a file (yes a file, *not* a patch) that changes absolutely *nothing* to existing users but it helps all those users who want to use systemd. I am very disappointed and confused. You should have known me better by now. - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang We are moving too quickly on bug #448882 ([Tracker] packages not providing systemd units). We should come to better consensus on systemd integration and we were getting there with the idea of INSTALL_MASK. I don't know that it is a working solution yet. I have to oppose adding unit files unless we have a way to opt out for reasons I gave earlier, regarding embedded systems where one needs to conserve space aggressively. And we may have found a way to do so without cluttering ebuilds with USE flags. Can I ask the systemd people to design a working solution for opting out? I can't support this initiative without such a solution and I would be happy to work with the systemd people to reach it, ie I'll test. I'm not a dev (though I would like to be...), but consider me interested in testing an opt-out method as well. I'm going to try INSTALL_MASK and see what happens. I'm not sure if any of my packages have systemd units yet, though. As far as resisting systemd, why is that so bad? Vertical integration is generally a bad idea with the sole exception of when your use case(s) line up perfectly with the ivory tower and you need all of the offered features. If Gentoo falls to systemd, there will literally be no Linux-based distros left to prevent it from taking over, and as a result Linux-based systems will become more and more tightly integrated, killing the choice that Gentoo truly stands for and homogenizing everything. That said, I realize that unit files don't intrude much on choice, and I'm happy that there is discussion on finding ways around it and making everyone happy (like INSTALL_MASK) instead of pushing ideas on users and telling them to deal with it. Out of curiosity though, is there a document that outlines how Gentoo Council members are chosen, when/if decisions can be revisited, and/or if a member's views are audited for neutrality? I'm somewhat interested in the way decisions are made within Gentoo.
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Symlinks are simple. They're filesystem feature, they're handled by kernel. The worst thing that could happen is symlink target disappearing -- but then it's: a) our responsibility to make sure to call eselect-init (if applies) when uninstalling an init system, b) something that would fail anyway if user did that by hand. Linux fallback mechanism is *good enough*. You may think that fallback to sysvinit is good but it's not. *If* I have my system set up to boot X, at some point the config for Y will get seriously outdated. I use systemd for a few months now, and last time I checked openrc boots somehow. But considering the general complexity of it, I wouldn't be much surprised if it failed in funny ways (like not being able to handle automounts properly), caused cruft on the filesystem or even caused *damage*. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. That said, switching /sbin/init is the reasonable way. If it fails, Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without unexpectedly switching init system to something else just because it was around. - init gets effectively switched only at boot/reboot, eselect init must keep track of the current active init and make sure the current init configuration is used till the system reboots, if we use the wrapper approach, it would pick up what's the new init at boot and that would be enough for simple cases, hooks on reboot are still needed for more complex ones. Pointless and overcomplex. If an init system actually fails to work when /sbin/init doesn't point to it, it is seriously broken by design. And because of that breakage, we keep stuff like 'telinit' or 'reboot' intact, and because of it systemd has 'pass-through' mode when linked to /sbin/init. - we could try to not have the changes to the current init systems ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init) Which means the kernel fallback will be dangerously active as I explained before. Just don't do it. # FOCUS My interest is mostly if not all on bb-init-openrc and slightly on runit-openrc. There are enough people involved in systemd and since I still consider it a dangerously frail implementation of a bad idea is better if I do not touch it at all. You've been able to keep this thread on topic very long. Good job! -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On Sun, 26 May 2013 01:24:03 -0500 Daniel Campbell dlcampb...@gmx.com wrote: On 05/25/2013 02:53 PM, Anthony G. Basile wrote: We are moving too quickly on bug #448882 ([Tracker] packages not providing systemd units). We should come to better consensus on systemd integration and we were getting there with the idea of INSTALL_MASK. I don't know that it is a working solution yet. I have to oppose adding unit files unless we have a way to opt out for reasons I gave earlier, regarding embedded systems where one needs to conserve space aggressively. And we may have found a way to do so without cluttering ebuilds with USE flags. Can I ask the systemd people to design a working solution for opting out? I can't support this initiative without such a solution and I would be happy to work with the systemd people to reach it, ie I'll test. I'm not a dev (though I would like to be...), but consider me interested in testing an opt-out method as well. I'm going to try INSTALL_MASK and see what happens. I'm not sure if any of my packages have systemd units yet, though. Please fix your e-mail client to send replies to the mail you are replying it, instead of the top mail in the thread. As far as resisting systemd, why is that so bad? Vertical integration is generally a bad idea with the sole exception of when your use case(s) line up perfectly with the ivory tower and you need all of the offered features. If Gentoo falls to systemd, there will literally be no Linux-based distros left to prevent it from taking over, and as a result Linux-based systems will become more and more tightly integrated, killing the choice that Gentoo truly stands for and homogenizing everything. It is bad because ebuilds are not place to put politics into. If you want to become dev, you should understand this. We are supposed to be serious people. Serious people don't break user systems or refuse to support them in the name of manifesting their wishes. It is bad because it's not systemd that's losing, it's Gentoo. Except for the fact that there's just a few people that take Gentoo seriously these days. Upstreams clearly show that they don't care. We can either sit in the corner and resent, or we can work on improving the situation. And going on flamewars or manifestations doesn't really improve anything, you should know that by now. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On Sat, 25 May 2013 15:53:21 -0400 Anthony G. Basile bluen...@gentoo.org wrote: We are moving too quickly on bug #448882 ([Tracker] packages not providing systemd units). We should come to better consensus on systemd integration and we were getting there with the idea of INSTALL_MASK. I don't know that it is a working solution yet. I have to oppose adding unit files unless we have a way to opt out for reasons I gave earlier, regarding embedded systems where one needs to conserve space aggressively. And we may have found a way to do so without cluttering ebuilds with USE flags. snarky You could drop conf.d and init.d files to save space, unit files are obviously smaller. /snarky Can I ask the systemd people to design a working solution for opting out? I can't support this initiative without such a solution and I would be happy to work with the systemd people to reach it, ie I'll test. INSTALL_MASK *is* a working solution. And I've designed app-portage/install-mask which sets it up for you. If you want something better, just integrate 'keywords' (like 'systemd', 'doc', 'man') into INSTALL_MASK, and be done with it. Just make sure to store the list of recognized keywords in the repo rather than keeping it rotting inside portage code. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 26 May 2013 02:13, Markos Chandras hwoar...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/25/2013 05:14 PM, Ben de Groot wrote: But if a co-maintainer pushes through a change that I oppose, then working together becomes quite difficult. In this case I opted to give up maintainership. Ben, We've been working together, in the same team(s), for more than 4 years and we never had a single problem in co-maintaining packages. I would never expected you to make so much noise because I committed a file (yes a file, *not* a patch) that changes absolutely *nothing* to existing users but it helps all those users who want to use systemd. I am very disappointed and confused. You should have known me better by now. It is exactly because of our good history together that I was so surprised and disappointed to see you disregarding my opinion in this, and dismissing it as my problem. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 26 May 2013 01:00, Pacho Ramos pa...@gentoo.org wrote: We can now have long discussions about upstream decisions, how to handle devrel problems... but I think it's much more easy: this kind of boycott attitudes should stop in favor of common sense. Common sense would be to recognize that systemd is a bad implementation of a bad idea, and to boycott it distro-wide. But you know what they say about common sense... -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
Am Samstag, den 25.05.2013, 15:53 -0400 schrieb Anthony G. Basile: On 05/25/2013 02:13 PM, Markos Chandras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/25/2013 05:14 PM, Ben de Groot wrote: But if a co-maintainer pushes through a change that I oppose, then working together becomes quite difficult. In this case I opted to give up maintainership. Ben, We've been working together, in the same team(s), for more than 4 years and we never had a single problem in co-maintaining packages. I would never expected you to make so much noise because I committed a file (yes a file, *not* a patch) that changes absolutely *nothing* to existing users but it helps all those users who want to use systemd. I am very disappointed and confused. You should have known me better by now. - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang We are moving too quickly on bug #448882 ([Tracker] packages not providing systemd units). We should come to better consensus on systemd integration and we were getting there with the idea of INSTALL_MASK. I don't know that it is a working solution yet. I have to oppose adding unit files unless we have a way to opt out for reasons I gave earlier, regarding embedded systems where one needs to conserve space aggressively. And we may have found a way to do so without cluttering ebuilds with USE flags. Even though I don't care about a couple of files more on my FS I would prefer to find a solution with functions provided by PMS, not portage alone. Can I ask the systemd people to design a working solution for opting out? I can't support this initiative without such a solution and I would be happy to work with the systemd people to reach it, ie I'll test. Maybe we have to find a more generic solution for this, because there is bug #235944 [1] which request extra config snippets for rsyslog added to various packages. Or is this something different? If yes, how? Best, Tiziano [1] https://bugs.gentoo.org/show_bug.cgi?id=235944
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 26 May 2013 00:48, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 00:14:36 +0800 Ben de Groot yng...@gentoo.org wrote: Unless I am mistaken, we did NOT agree anywhere that Gentoo maintainers MUST add systemd support when upstream does not ship such files. We did agree that Gentoo maintainers are not supposed to work on enabling systemd support if they don't want to. OK, that sounds good. On the other hand, we also agreed that they shouldn't refuse unit files if anyone else does the work for them. Where is this policy documented? [...] And you misunderstood: it is systemd that is aggressively opposed to Gentoo. But apparently that doesn't bother some of our developers and Gentoo is becoming more and more welcoming to it. Protecting freedom through taking away the freedom of using systemd? Makes sense really. That would be similar to the way the GPL protects software freedom. Does that not make sense to you either? But it isn't even like that. I'm not taking away anyone's freedom to use systemd. You can do so if you wish. You can add unit files to your system by yourself, or use an overlay. There are various ways this could be realized even within Gentoo. But you seem to dismiss all of those, and will only be happy by forcing maintainers to add support to packages they maintain, even if they believe it is a bad idea. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/26/2013 01:55 AM, Michał Górny wrote: On Sun, 26 May 2013 01:24:03 -0500 Daniel Campbell dlcampb...@gmx.com wrote: On 05/25/2013 02:53 PM, Anthony G. Basile wrote: We are moving too quickly on bug #448882 ([Tracker] packages not providing systemd units). We should come to better consensus on systemd integration and we were getting there with the idea of INSTALL_MASK. I don't know that it is a working solution yet. I have to oppose adding unit files unless we have a way to opt out for reasons I gave earlier, regarding embedded systems where one needs to conserve space aggressively. And we may have found a way to do so without cluttering ebuilds with USE flags. Can I ask the systemd people to design a working solution for opting out? I can't support this initiative without such a solution and I would be happy to work with the systemd people to reach it, ie I'll test. I'm not a dev (though I would like to be...), but consider me interested in testing an opt-out method as well. I'm going to try INSTALL_MASK and see what happens. I'm not sure if any of my packages have systemd units yet, though. Please fix your e-mail client to send replies to the mail you are replying it, instead of the top mail in the thread. As far as resisting systemd, why is that so bad? Vertical integration is generally a bad idea with the sole exception of when your use case(s) line up perfectly with the ivory tower and you need all of the offered features. If Gentoo falls to systemd, there will literally be no Linux-based distros left to prevent it from taking over, and as a result Linux-based systems will become more and more tightly integrated, killing the choice that Gentoo truly stands for and homogenizing everything. It is bad because ebuilds are not place to put politics into. If you want to become dev, you should understand this. We are supposed to be serious people. Serious people don't break user systems or refuse to support them in the name of manifesting their wishes. It is bad because it's not systemd that's losing, it's Gentoo. Except for the fact that there's just a few people that take Gentoo seriously these days. Upstreams clearly show that they don't care. We can either sit in the corner and resent, or we can work on improving the situation. And going on flamewars or manifestations doesn't really improve anything, you should know that by now. Sorry, I sent the e-mail to the list under the wrong e-mail address and retooled a forward to try to correct it. It seems my idea didn't work. I'm using Thunderbird, so if this reply is screwed up as well, I'd appreciate some insight to fix it. I agree that user systems shouldn't be broken, and that devs should be serious about their responsibilities. I'm not exactly sure how Gentoo is losing out on anything, but that's probably because I'm biased against systemd. From the opposite side of the fence, Gentoo may become less relevant to the vertical integration people if it doesn't support systemd in some form. It's a choice and thus it should be supported. If INSTALL_MASK is really all that's needed to protect anti-systemd people, then perhaps the Gentoo team doesn't need to do anything at all, so that's awesome. Each time I see this come up I wish there wasn't so much activism present in the GNU/Linux world so people could focus more on fixing problems and less on politics, but the politics have to be acted on and/or against or it gets in the way of problem-solving and software diversity. I stick with Gentoo because most of the people working on it seem so level-headed and keep the idea of choice in mind. I guess I'm rambling, so I guess I'll close with a Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRobu1AAoJEJUrb08JgYgH198H/38gtUviiMCV3GZGm/1kiORO njwbiwqZm3HHycrUxDa5jOUt6HPN7MH+pTvNf/Cl16zv1/CxiOpr4oJHCJFUDTd7 3vpmexIeN82Qw3RKW3ADuwOxBjgUbPz+btMN8a2szVnwl524BHldD1wiQ9E6BxRy zSbqWR3VcNeZpCD9nvXBj4C9CbXO738EWRcAugGG4/3Vw1ntuYGvhrZxeDEcZtFa 4sVaRI6MPuWetvF0KbgnLQc9N3XgSNidb+LyIaG6oO1wG3ODldrkKwtGLMu8/sG6 NA0CEH0MTTlb2ErdW/DT6g/++Wu6qz4aZc+XWwxj1wK9uTGWiK+sDzuhTzLrunM= =T3wH -END PGP SIGNATURE-
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
El dom, 26-05-2013 a las 15:15 +0800, Ben de Groot escribió: On 26 May 2013 01:00, Pacho Ramos pa...@gentoo.org wrote: We can now have long discussions about upstream decisions, how to handle devrel problems... but I think it's much more easy: this kind of boycott attitudes should stop in favor of common sense. Common sense would be to recognize that systemd is a bad implementation of a bad idea, and to boycott it distro-wide. But you know what they say about common sense... -- Cheers, Ben | yngwin Gentoo developer Call it then: don't hurt others only because you hate systemd. Again, including that unit file won't hurt you at all
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
El dom, 26-05-2013 a las 09:22 +0200, Tiziano Müller escribió: [...] Can I ask the systemd people to design a working solution for opting out? I can't support this initiative without such a solution and I would be happy to work with the systemd people to reach it, ie I'll test. Maybe we have to find a more generic solution for this, because there is bug #235944 [1] which request extra config snippets for rsyslog added to various packages. Or is this something different? If yes, how? Best, Tiziano [1] https://bugs.gentoo.org/show_bug.cgi?id=235944 Probably a better solution should be found but, until then, we should behave with unit files like we behave for all other similar cases (like logrotate, even init.d files for openrc, bash-completion files...)
[gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 00:14:36 +0800 Ben de Groot yng...@gentoo.org wrote: Systemd is diametrically opposed to the FreeBSD, customization, extreme configurability, and top-notch developer community aspects of that. Systemd upstream developers have made it abundantly clear they are not interested in working with Gentoo developers to see to the needs of source-based distros. They stand for vertical integration instead of customization and configurability. And you misunderstood: it is systemd that is aggressively opposed to Gentoo. But apparently that doesn't bother some of our developers and Gentoo is becoming more and more welcoming to it. By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Although some of the ideas (esp. wrt targets) are near to crazy and awfully hard to understand, that's what we have and trying to do something else is eventually going to make people's lives harder. We should *really* work on supporting the unit files within OpenRC (aside to init.d files). That's a way to at least: a) reuse the work that has been done upstream already (when it was done), b) have common service names and startup behavior in all relevant distros (which is really beneficial to the users). Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. On the completely different topic, I agree that systemd design is far from the best and the way it's maintained is just bad. I was interested in the past in creating an improved alternative using compatible file format and libraries, while choosing a better design, improving portability and keeping stuff less integrated. But the fact is -- I doubt it will make sense, much like the eudev project. And it will take much more work, and give much less appreciation. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. Then, it will require people working on it. People who know the details of various systems and who are willing to spend their time on it. And there wouldn't be much of people really willing to work on it. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. It is possible that systemd upstream will steal a few patches or ideas from it. Yet they will never apply any of the really important changes, so the project will have to be maintained indefinitely. The only hope for it would be to win over systemd users which I doubt will happen. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On Sun, 26 May 2013 15:15:18 +0800 Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 01:00, Pacho Ramos pa...@gentoo.org wrote: We can now have long discussions about upstream decisions, how to handle devrel problems... but I think it's much more easy: this kind of boycott attitudes should stop in favor of common sense. Common sense would be to recognize that systemd is a bad implementation of a bad idea, and to boycott it distro-wide. But you know what they say about common sense... As in, say, lastrite GNOME and tell users to switch to other distro? Or maybe everything using udev? Sounds much like the way to get the 'one distro' dream some people have. But wasn't the intent opposite? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On Sun, 26 May 2013 15:23:44 +0800 Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 00:48, Michał Górny mgo...@gentoo.org wrote: On the other hand, we also agreed that they shouldn't refuse unit files if anyone else does the work for them. Where is this policy documented? Nowhere, I think. I've seen it coming in the late thread, looked common sense enough to me. If it is to be documented, I think we should document it in a more general fashion. To cover all stuff like completions, logrotate and so on. [...] And you misunderstood: it is systemd that is aggressively opposed to Gentoo. But apparently that doesn't bother some of our developers and Gentoo is becoming more and more welcoming to it. Protecting freedom through taking away the freedom of using systemd? Makes sense really. That would be similar to the way the GPL protects software freedom. Does that not make sense to you either? No. The initial version of that response even used 'FSF' but I've decided not to flame it. But it isn't even like that. I'm not taking away anyone's freedom to use systemd. You can do so if you wish. You can add unit files to your system by yourself, or use an overlay. There are various ways this could be realized even within Gentoo. You know how fragile that is, don't you? But you seem to dismiss all of those, and will only be happy by forcing maintainers to add support to packages they maintain, even if they believe it is a bad idea. Do I? As far as I'm concerned, I always kindly asked on IRC or opened bugs for it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On Sun, 26 May 2013 09:22:05 +0200 Tiziano Müller dev-z...@gentoo.org wrote: Am Samstag, den 25.05.2013, 15:53 -0400 schrieb Anthony G. Basile: We are moving too quickly on bug #448882 ([Tracker] packages not providing systemd units). We should come to better consensus on systemd integration and we were getting there with the idea of INSTALL_MASK. I don't know that it is a working solution yet. I have to oppose adding unit files unless we have a way to opt out for reasons I gave earlier, regarding embedded systems where one needs to conserve space aggressively. And we may have found a way to do so without cluttering ebuilds with USE flags. Even though I don't care about a couple of files more on my FS I would prefer to find a solution with functions provided by PMS, not portage alone. PMS doesn't cover configuration, and I feel this is mostly a configuration problem. Can I ask the systemd people to design a working solution for opting out? I can't support this initiative without such a solution and I would be happy to work with the systemd people to reach it, ie I'll test. Maybe we have to find a more generic solution for this, because there is bug #235944 [1] which request extra config snippets for rsyslog added to various packages. Or is this something different? If yes, how? Well, I don't know rsyslog and I have no real idea where those files end up. But if they end up in a common directory, it's exactly the kind of thing we can handle with INSTALL_MASK. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
El dom, 26-05-2013 a las 15:23 +0800, Ben de Groot escribió: [...] But it isn't even like that. I'm not taking away anyone's freedom to use systemd. You are doing as you are forcing them to have a semi-usable setup when merging packages. You can do so if you wish. You can add unit files to your system by yourself, or use an overlay. There are various ways this could be realized even within Gentoo. Who are you to force people to use an overlay? Why are you forbidding the inclusion of unit files? Maybe you could also have a separate overlay called systemd-haters to maintain that ebuilds done to obstacle systemd usage. But you seem to dismiss all of those, and will only be happy by forcing maintainers to add support to packages they maintain, even if they believe it is a bad idea. Nobody is forcing you to maintain that unit file: the unit file will be maintained by the other co-maintainer or systemd team if he cannot do that.
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
El dom, 26-05-2013 a las 08:55 +0200, Michał Górny escribió: [...] As far as resisting systemd, why is that so bad? Vertical integration is generally a bad idea with the sole exception of when your use case(s) line up perfectly with the ivory tower and you need all of the offered features. If Gentoo falls to systemd, there will literally be no Linux-based distros left to prevent it from taking over, and as a result Linux-based systems will become more and more tightly integrated, killing the choice that Gentoo truly stands for and homogenizing everything. It is bad because ebuilds are not place to put politics into. If you want to become dev, you should understand this. We are supposed to be serious people. Serious people don't break user systems or refuse to support them in the name of manifesting their wishes. It is bad because it's not systemd that's losing, it's Gentoo. Except for the fact that there's just a few people that take Gentoo seriously these days. Upstreams clearly show that they don't care. We can either sit in the corner and resent, or we can work on improving the situation. And going on flamewars or manifestations doesn't really improve anything, you should know that by now. It's also bad because you are affecting to a lot of people that can/want to use systemd, forcing you to have semi-usable setups because of your personal preferences.
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 00:14:36 +0800 Ben de Groot yng...@gentoo.org wrote: Systemd is diametrically opposed to the FreeBSD, customization, extreme configurability, and top-notch developer community aspects of that. Systemd upstream developers have made it abundantly clear they are not interested in working with Gentoo developers to see to the needs of source-based distros. They stand for vertical integration instead of customization and configurability. And you misunderstood: it is systemd that is aggressively opposed to Gentoo. But apparently that doesn't bother some of our developers and Gentoo is becoming more and more welcoming to it. By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Although some of the ideas (esp. wrt targets) are near to crazy and awfully hard to understand, that's what we have and trying to do something else is eventually going to make people's lives harder. We should *really* work on supporting the unit files within OpenRC (aside to init.d files). That's a way to at least: a) reuse the work that has been done upstream already (when it was done), b) have common service names and startup behavior in all relevant distros (which is really beneficial to the users). Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. On the completely different topic, I agree that systemd design is far from the best and the way it's maintained is just bad. I was interested in the past in creating an improved alternative using compatible file format and libraries, while choosing a better design, improving portability and keeping stuff less integrated. But the fact is -- I doubt it will make sense, much like the eudev project. And it will take much more work, and give much less appreciation. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. Then, it will require people working on it. People who know the details of various systems and who are willing to spend their time on it. And there wouldn't be much of people really willing to work on it. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. It is possible that systemd upstream will steal a few patches or ideas from it. Yet they will never apply any of the really important changes, so the project will have to be maintained indefinitely. The only hope for it would be to win over systemd users which I doubt will happen. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? I agree it would be pretty hard to carve out a niche for this. Personally I would see more in runit. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 21:52:28 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote It has to be done *VERY* early at boot, or else we're back to the problem you described above. Not sure what you mean with very early, you don't really have control over this anyway; the earliest point at which you can reliably do this is to turning init itself into a wrapper. It's almost like a brain surgeon operating on himself. That's if externally you turn it into a symlink, not with a wrapper. 1) boot into single mode before doing the changeover. Both grub and lilo support single mode boot as per... http://www.gentoo-wiki.info/TIP_Booting_into_single_user_mode And EFI? This sounds a bit of an overkill. What's wrong with a wrapper? 2) have the setup/switchover mechanism built into the Gentoo minimal install ISO. The advantage here is that if the system ends up no longer bootable off the harddrive, you can still boot from the ISO, chroot into the system on the harddrive, and send emails to the gentoo-user list asking for help G. Users can already use eselect in their chroot. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 04:02:56 +0200 Peter Stuge pe...@stuge.se wrote: By take effect I mean that the filesystem should be modified in such a way that the next boot will use what I selected. No further action which could fail should be required beyond the eselect command. Unless the eselect command has successfully modified the filesystem I can't really know that my system will boot with what I have selected, ie. eselect does not provide any useful feedback, because it can not. That's exactly what I've described in another mail in another subthread. http://thread.gmane.org/gmane.linux.gentoo.devel/85778/focus=85789 Snippet of what I said: Sounds like we would have two files like 'current_init' and 'boot_init' and `eselect init ...` would update 'boot_init'. Then, the first `init` invocation on boot would update 'current_init' with the value of 'boot_init'; latter `init` invocations can then read out 'current_init', which is not to be touched by `eselect init ...`. This assumes that you would be working with a wrapper, not a symlink. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 08:43:32 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Symlinks are simple. They're filesystem feature, they're handled by kernel. The worst thing that could happen is symlink target disappearing -- but then it's: a) our responsibility to make sure to call eselect-init (if applies) when uninstalling an init system, b) something that would fail anyway if user did that by hand. Linux fallback mechanism is *good enough*. You may think that fallback to sysvinit is good but it's not. *If* I have my system set up to boot X, at some point the config for Y will get seriously outdated. I use systemd for a few months now, and last time I checked openrc boots somehow. But considering the general complexity of it, I wouldn't be much surprised if it failed in funny ways (like not being able to handle automounts properly), caused cruft on the filesystem or even caused *damage*. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. That said, switching /sbin/init is the reasonable way. If it fails, Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without unexpectedly switching init system to something else just because it was around. I agree with this. But changing symlinks is not as easy on running system (since it can cause inconsistence during rebooot). I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. Thus this eselect init will let the user confirm and then trigger reboot. I do not think that users will change init all the time, thus make it better safe and more complex in this change is better than check and wrap in all the boots. Otherwise interesting is preinit handler in OpenWrt: http://wiki.openwrt.org/doc/techref/process.boot http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit http://wiki.openwrt.org/doc/techref/preinit_mount Robert. - init gets effectively switched only at boot/reboot, eselect init must keep track of the current active init and make sure the current init configuration is used till the system reboots, if we use the wrapper approach, it would pick up what's the new init at boot and that would be enough for simple cases, hooks on reboot are still needed for more complex ones. Pointless and overcomplex. If an init system actually fails to work when /sbin/init doesn't point to it, it is seriously broken by design. And because of that breakage, we keep stuff like 'telinit' or 'reboot' intact, and because of it systemd has 'pass-through' mode when linked to /sbin/init. - we could try to not have the changes to the current init systems ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init) Which means the kernel fallback will be dangerously active as I explained before. Just don't do it. # FOCUS My interest is mostly if not all on bb-init-openrc and slightly on runit-openrc. There are enough people involved in systemd and since I still consider it a dangerously frail implementation of a bad idea is better if I do not touch it at all. You've been able to keep this thread on topic very long. Good job!
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 10:58:23 +0200 Robert David robert.david.pub...@gmail.com wrote: On Sun, 26 May 2013 08:43:32 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Symlinks are simple. They're filesystem feature, they're handled by kernel. The worst thing that could happen is symlink target disappearing -- but then it's: a) our responsibility to make sure to call eselect-init (if applies) when uninstalling an init system, b) something that would fail anyway if user did that by hand. Linux fallback mechanism is *good enough*. You may think that fallback to sysvinit is good but it's not. *If* I have my system set up to boot X, at some point the config for Y will get seriously outdated. I use systemd for a few months now, and last time I checked openrc boots somehow. But considering the general complexity of it, I wouldn't be much surprised if it failed in funny ways (like not being able to handle automounts properly), caused cruft on the filesystem or even caused *damage*. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. That said, switching /sbin/init is the reasonable way. If it fails, Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without unexpectedly switching init system to something else just because it was around. I agree with this. But changing symlinks is not as easy on running system (since it can cause inconsistence during rebooot). It is *easy*. ln -s /sbin/newinit /sbin/init.new mv /sbin/init.new /sbin/init Easy and atomic. The inconsistency potential is similar to one given by init upgrades. Yet we don't do anything magical to defer init upgrade until reboot, and that's why the upgrades go smoothly. I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. This can be done two ways. One is hacking into init (RC) reboot procedure. It's fragile, it needs to be fit into the right moment and I'm not sure if all inits will handle this without actually needing to patch the code. And in the end, the init gets replaced before init stops working anyway. The other is going beside init and directly into the reboot. This either requires kernel hacking (please don't!) or hacking the reboot procedure in init code. And of course remounting R/W, then writing, remounting back... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 10:58:23 +0200 Robert David robert.david.pub...@gmail.com wrote: Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months.. I agree with this. But changing symlinks is not as easy on running system (since it can cause inconsistence during rebooot). I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. Thus this eselect init will let the user confirm and then trigger reboot. I do not think that users will change init all the time, thus make it better safe and more complex in this change is better than check and wrap in all the boots. Otherwise interesting is preinit handler in OpenWrt: http://wiki.openwrt.org/doc/techref/process.boot http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit http://wiki.openwrt.org/doc/techref/preinit_mount In other words, if you go for the symlink approach you're just moving complexity to your system instead of into the boot; I don't see why a wrapper would grow to openrc size, that's just a bold exaggeration. I'd rather have a clean wrapper that just works than an unclean way to cover the reboot madness that comes along; forcing a reboot, really? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:20:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 10:58:23 +0200 Robert David robert.david.pub...@gmail.com wrote: On Sun, 26 May 2013 08:43:32 +0200 Michał Górny mgo...@gentoo.org wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Symlinks are simple. They're filesystem feature, they're handled by kernel. The worst thing that could happen is symlink target disappearing -- but then it's: a) our responsibility to make sure to call eselect-init (if applies) when uninstalling an init system, b) something that would fail anyway if user did that by hand. Linux fallback mechanism is *good enough*. You may think that fallback to sysvinit is good but it's not. *If* I have my system set up to boot X, at some point the config for Y will get seriously outdated. I use systemd for a few months now, and last time I checked openrc boots somehow. But considering the general complexity of it, I wouldn't be much surprised if it failed in funny ways (like not being able to handle automounts properly), caused cruft on the filesystem or even caused *damage*. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. That said, switching /sbin/init is the reasonable way. If it fails, Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without unexpectedly switching init system to something else just because it was around. I agree with this. But changing symlinks is not as easy on running system (since it can cause inconsistence during rebooot). It is *easy*. ln -s /sbin/newinit /sbin/init.new mv /sbin/init.new /sbin/init Easy and atomic. The inconsistency potential is similar to one given by init upgrades. Yet we don't do anything magical to defer init upgrade until reboot, and that's why the upgrades go smoothly. You are right. Even though, it is highly appreciated to inform user on urgent reboot. I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. This can be done two ways. One is hacking into init (RC) reboot procedure. It's fragile, it needs to be fit into the right moment and I'm not sure if all inits will handle this without actually needing to patch the code. And in the end, the init gets replaced before init stops working anyway. The other is going beside init and directly into the reboot. This either requires kernel hacking (please don't!) or hacking the reboot procedure in init code. And of course remounting R/W, then writing, remounting back... I did not say it will be easy. Still I think there is space to investigate deeply how to handle that more cleanly (eg: onetime late shutdonw initscript/unit). No one will be hacking kernel:) Robert.
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:20:25 +0200 Michał Górny mgo...@gentoo.org wrote: It is *easy*. ln -s /sbin/newinit /sbin/init.new mv /sbin/init.new /sbin/init Easy and atomic. The inconsistency potential is similar to one given by init upgrades. Yet we don't do anything magical to defer init upgrade until reboot, and that's why the upgrades go smoothly. Easy isn't always good. It's not atomic since you can't reboot and because of that I wouldn't call it smooth either. I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. This can be done two ways. One is hacking into init (RC) reboot procedure. It's fragile, it needs to be fit into the right moment and I'm not sure if all inits will handle this without actually needing to patch the code. And in the end, the init gets replaced before init stops working anyway. You're making things way more complex than a wrapper would do. I'm not a fan of using the words hacking, fragile and not sure for selling an approach; so, why were you suggesting the symlink approach? The other is going beside init and directly into the reboot. This either requires kernel hacking (please don't!) Yes, please don't, it's against our general objectives. http://www.gentoo.org/proj/en/kernel/maintenance.xml#doc_chap3 Furthermore, even if you would consider this then you can't be guaranteed that everyone uses genpatches; and I don't think we would want this in the eclass either, its users will very likely object. or hacking the reboot procedure in init code. And of course remounting R/W, then writing, remounting back... I don't think patching them is a reliable approach; it steps away from being loosely coupled and therefore makes it harder to understand, you are changing multiple things at once and introduce a maintenance burden. With a wrapper, you don't have a problem with any of those... Loose coupling, high cohesion. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, May 26, 2013 at 4:32 AM, Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. Rich
Re: [gentoo-dev] eselect init
On 5/26/13 8:43 AM, Michał Górny wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Symlinks are simple. They're filesystem feature, they're handled by kernel. The worst thing that could happen is symlink target disappearing -- but then it's: a) our responsibility to make sure to call eselect-init (if applies) when uninstalling an init system, b) something that would fail anyway if user did that by hand. Linux fallback mechanism is *good enough*. You may think that fallback to sysvinit is good but it's not. *If* I have my system set up to boot X, at some point the config for Y will get seriously outdated. Have you tested it? Do you know what is the reaction of do_exec on a dangling symlink? I use systemd for a few months now, and last time I checked openrc boots somehow. But considering the general complexity of it, I wouldn't be much surprised if it failed in funny ways (like not being able to handle automounts properly), caused cruft on the filesystem or even caused *damage*. openrc is *simpler* much *simpler* than systemd, stop with that. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. wc -l is a good answer to your concern. Some scripts have to be simplified, that's a given (e.g. Fabio pointed the lvm one can be improved a lot) but it isn't the case for most of them. Pointless and overcomplex. If an init system actually fails to work when /sbin/init doesn't point to it, it is seriously broken by design. And because of that breakage, we keep stuff like 'telinit' or 'reboot' intact, and because of it systemd has 'pass-through' mode when linked to /sbin/init. Check your facts, systemd either understands a flavour of inittab or the other or none at all. Which means the kernel fallback will be dangerously active as I explained before. Just don't do it. It is not dangerous beside for those that have an inittab with rm -fR / lu
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 5/26/13 9:45 AM, Michał Górny wrote: As in, say, lastrite GNOME and tell users to switch to other distro? Or maybe everything using udev? Sounds much like the way to get the 'one distro' dream some people have. But wasn't the intent opposite? eudev was made on purpose to let people avoid systemd if they wanted, and it is why people involved on it got stalked and had that much fun. lu
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:21:25 +0200 Tom Wijsman tom...@gentoo.org wrote: On Sun, 26 May 2013 10:58:23 +0200 Robert David robert.david.pub...@gmail.com wrote: Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months.. I agree with this. But changing symlinks is not as easy on running system (since it can cause inconsistence during rebooot). I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. Thus this eselect init will let the user confirm and then trigger reboot. I do not think that users will change init all the time, thus make it better safe and more complex in this change is better than check and wrap in all the boots. Otherwise interesting is preinit handler in OpenWrt: http://wiki.openwrt.org/doc/techref/process.boot http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit http://wiki.openwrt.org/doc/techref/preinit_mount In other words, if you go for the symlink approach you're just moving complexity to your system instead of into the boot; I don't see why a wrapper would grow to openrc size, that's just a bold exaggeration. Newer say that wrapper will grow openrc size, and also dont know why it would be bad. The point is somewhere else. I really dont know how many user will switch inits and how many of them will do this regularly. But the wrapper will be executed every boot. So even a tiny mistake can produce booting problems even for those who did not wanted to change anything in init process. On the other hand mistake in some system process will affect only those who would actually switching. It is only calculation of possible risks. I also did not say it must be done the reboot way I mentioned, this is only and different point what can be though about. I'd rather have a clean wrapper that just works than an unclean way to cover the reboot madness that comes along; forcing a reboot, really? I do not see point not forcing reboot when I'm switching init, or let say suggesting. When you update your kernel config, rebuild and install you also can stay working, but you have to be prepared to have nonworking modules that was not inserted before.
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On Sun, May 26, 2013 at 3:43 AM, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 15:23:44 +0800 Ben de Groot yng...@gentoo.org wrote: Where is this policy documented? Nowhere, I think. I've seen it coming in the late thread, looked common sense enough to me. If it is to be documented, I think we should document it in a more general fashion. To cover all stuff like completions, logrotate and so on. As others have already pointed out, we are an organization, not a CPU. We can't make EVERYTHING a rule, and devs should act in a cooperative manner so that this remains the case. Sure, this can be made into a policy, and if things get out of hand I'm sure it will be. I'm not quite sure I see the need yet, as we don't have an example yet of a maintainer not cooperating with the systemd team on the installation of init files (in the present example Ben isn't actually a maintainer, since he stepped down). If Ben wants to boycott systemd by not maintaining any packages that support it, that is his choice. I just suspect that the end result of that will be that he'll end up not maintaining much of anything. I'd hate to see that happen, as it would be a loss for Gentoo. But, frankly, letting any one person dictate the direction of the entire distro by essentially threatening to quit would be worse. Gentoo is about choice - and the nature of choice is that most of the choices it supports are ones that you wouldn't personally make. We do a reasonably good job letting everybody have their cake and eat it too. However, it really isn't an appropriate distro for absolute purists of almost any kind - it reeks of compromise. We package proprietary software (we don't redistribute the copyrighted parts), we more-or-less run on Windows/OSX, we support that X32 alternate architecture that some believe has no useful purpose, and so on. If you really want to influence the battle of the init implementations, then write code, not emails. Maybe that is a wrapper that allows OpenRC to support systemd units. Maybe that is more functionality for OpenRC. Maybe it is something else. However, trying to influence things by just spitting into the wind isn't going to do much but get your face dirty. Sure, devs can quit, but that isn't just a loss for Gentoo. Frankly if your main goal in life is to avoid systemd then you're better off supporting Gentoo which is likely to support that option nearly forever far better than any other distro. Rich
Re: [gentoo-dev] eselect init
On Sun, May 26, 2013 at 6:01 AM, Robert David robert.david.pub...@gmail.com wrote: Newer say that wrapper will grow openrc size, and also dont know why it would be bad. The point is somewhere else. I really dont know how many user will switch inits and how many of them will do this regularly. But the wrapper will be executed every boot. So even a tiny mistake can produce booting problems even for those who did not wanted to change anything in init process. On the other hand mistake in some system process will affect only those who would actually switching. It is only calculation of possible risks. You can have your cake and eat it too. Just don't call the wrapper init. Somebody else already suggested leaving the init implementations alone and stick the wrapper in a new binary that would need to be enabled specifically in the boot/kernel configuration. So if grub points to /sbin/einit then it runs the wrapper. If it just points to openrc/systemd then it directly executes them and bypasses the wrapper. That means that this whole thing only impacts those who install it, which is the best way to implement something experimental in the first place. Granted, I don't know the limitations of the EFI bootloaders that are out there, but this still seems like something better solved via grub configuration. When I implemented systemd in one of my VMs I just added a grub line to boot back to openrc. Rich
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 4:32 AM, Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. Rich +1 I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. Robert.
Re: [gentoo-dev] eselect init
Rich Freeman schrieb: Granted, I don't know the limitations of the EFI bootloaders that are out there, but this still seems like something better solved via grub configuration. When I implemented systemd in one of my VMs I just added a grub line to boot back to openrc. EFI stub kernels just need init=/sbin/wrappername in CONFIG_CMDLINE in order to use the wrapper. However, in case of breakage in the wrapper, you would need to boot a fallback kernel or access the EFI shell (not all UEFI implementations allow the latter). Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 9:37 AM, Michał Górny wrote: By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Unit files had been considered when I started exploring the idea, sadly Joost shown me their limitation wouldn't make people life exactly happy. Although some of the ideas (esp. wrt targets) are near to crazy and awfully hard to understand, that's what we have and trying to do something else is eventually going to make people's lives harder. Making better mousetraps usually works fine: as long you have generators that are good enough to get something working nobody would complain. We should *really* work on supporting the unit files within OpenRC (aside to init.d files). That's a way to at least: a) reuse the work that has been done upstream already (when it was done), b) have common service names and startup behavior in all relevant distros (which is really beneficial to the users). Can be done notwithstanding the rest. Considering the design of OpenRC itself, it wouldn't be *that hard*. It is sort of simple. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. A compiler is an option as well, as said unit - runscript should map fine. On the completely different topic, I agree that systemd design is far from the best and the way it's maintained is just bad. I was interested in the past in creating an improved alternative using compatible file format and libraries, while choosing a better design, improving portability and keeping stuff less integrated. But the fact is -- I doubt it will make sense, much like the eudev project. And it will take much more work, and give much less appreciation. Having stand alone component would probably win you many friends and if the whole thing could work on something non-linux-latest-with-latest-glibc you'd have one less technical concern. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. You make clean blueprints, get enough people agreeing with them and implement simple workalike for what you care about. For example logind seems to be the current fad. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. systemd haters, as you name them, could be split in few groups: - those that consider systemd a bad idea because it is a single item with many parts that would break horribly, if your idea is to make it less tightly coupled and with less parts many would consider helping. - those that consider systemd a bad idea because of the force feeding theme started with udev incorporation and continued with logind and such, again if you are creating alternatives the people would help gladly. - those that consider key part of systemd just wrong the limitation in the unit format or path activation as panacea, in that case you have to make clear the scope of your project, you might win few or lose some. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. Make it bsd and they would consider helping. It is possible that systemd upstream will steal a few patches or ideas from it. Yet they will never apply any of the really important changes, so the project will have to be maintained indefinitely. The only hope for it would be to win over systemd users which I doubt will happen. Or just make something useful, winning or losing is for the people using it. If it works and works fine people will use it. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? Probably would be better sit down, figure out exactly what you want and see who has interest: E.g. Init-project - portable - must work on non-linux and non-glibc more or less decently - modular- loose coupling of functionality - robust - the core functionality must not crash or remain inconsistent because of libdbus or such often occurring problems unrelated to - compatible - should grok at least a good subset of systemd unit files. On a side note I
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:55:24 +0200 Luca Barbato lu_z...@gentoo.org wrote: Openrc is small, but the wrapper really needs to know which is which It doesn't need to, it just needs to kick off the right init process. If you think it does need to, please elaborate. and worst case switch inittab. You could keep this kind of logic outside the wrapper, specific to the init system; such that the wrapper and therefore the shared part of the boot regardless of init system stays as small as possible. This could be even something you could let the eselect script change, the inittab is only needed at boot time as far as I can recall. openrc is *simpler* much *simpler* than systemd, stop with that. Simpler is not necessarily better, stop with flames you don't back up; and if you do back them up, then please keep it outside of the ML. You're contributing to sidetracking your own discussion. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. wc -l is a good answer to your concern. Some scripts have to be simplified, that's a given (e.g. Fabio pointed the lvm one can be improved a lot) but it isn't the case for most of them. If we're really going to have this discussion and you really care about wc -l, maybe we should compress init scripts and service units; perhaps we could then combine them into one file to spare inodes too. Joke aside; the other reason, maintainability, is a good one. It is not dangerous beside for those that have an inittab with rm -fR / Root preservation should make this safe. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:55:24 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 8:43 AM, Michał Górny wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. Did anyone notice already that moving stuff around actually requires rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit of init/RC work. And what will happen if moving the files fail? What if half of configuration belongs to old init, and half to new? And it all happens automagically on boot, on an incomplete system without any console started, without Internet connection established and without any serious mean of help. Symlinks are simple. They're filesystem feature, they're handled by kernel. The worst thing that could happen is symlink target disappearing -- but then it's: a) our responsibility to make sure to call eselect-init (if applies) when uninstalling an init system, b) something that would fail anyway if user did that by hand. Linux fallback mechanism is *good enough*. You may think that fallback to sysvinit is good but it's not. *If* I have my system set up to boot X, at some point the config for Y will get seriously outdated. Have you tested it? Do you know what is the reaction of do_exec on a dangling symlink? And did you? You keep repeating this and jumping straight to developing work-arounds without even waiting for an answer. And I think William has already spoken that the code supports it. In any case, I've just tested it. Replaced /sbin/init with a dangling symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh as a fallback. I use systemd for a few months now, and last time I checked openrc boots somehow. But considering the general complexity of it, I wouldn't be much surprised if it failed in funny ways (like not being able to handle automounts properly), caused cruft on the filesystem or even caused *damage*. openrc is *simpler* much *simpler* than systemd, stop with that. OpenRC relies on a few layers of various tools plus a lot of init scripts written by different people. Those init scripts include tasks such as parsing configuration files (well, more of grepping them) and manipulating runtime files. The complexity of OpenRC is the sum of all that. To make this point cleaner to you: what if the fallback ran systemd instead? As in, init gets broken somehow and kernel falls back to starting systemd on your unprepared OpenRC system. Is this a behavior you'd like? What I'm telling is: if user uses A as init system (and wanted to switch to B), last thing he'd expect is C being started. Configuration for OpenRC may be long unmaintained, may start services which are not supposed to be started anymore and so on. And since you've been failing long at keeping init.d scripts simple and reasonable, the damage potential is not something purely theoretical. wc -l is a good answer to your concern. Some scripts have to be simplified, that's a given (e.g. Fabio pointed the lvm one can be improved a lot) but it isn't the case for most of them. We're not talking about percentages here. A *single* fragile script is enough to cause trouble. Ten good ones won't revert it. Pointless and overcomplex. If an init system actually fails to work when /sbin/init doesn't point to it, it is seriously broken by design. And because of that breakage, we keep stuff like 'telinit' or 'reboot' intact, and because of it systemd has 'pass-through' mode when linked to /sbin/init. Check your facts, systemd either understands a flavour of inittab or the other or none at all. What are you talking about now? I was just saying that *if* you link /sbin/init to systemd, and you're running sysvinit, 'init foo' will be passed through to telinit. But now I see that I was wrong and it actually happened when 'systemctl' was symlinked to 'init'. Nevermind then. In any case, keeping all the tools like
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:45:38 +0200 Tom Wijsman tom...@gentoo.org wrote: On Sun, 26 May 2013 11:20:25 +0200 Michał Górny mgo...@gentoo.org wrote: It is *easy*. ln -s /sbin/newinit /sbin/init.new mv /sbin/init.new /sbin/init Easy and atomic. The inconsistency potential is similar to one given by init upgrades. Yet we don't do anything magical to defer init upgrade until reboot, and that's why the upgrades go smoothly. Easy isn't always good. It's not atomic since you can't reboot and because of that I wouldn't call it smooth either. Can't you? How come? I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. This can be done two ways. One is hacking into init (RC) reboot procedure. It's fragile, it needs to be fit into the right moment and I'm not sure if all inits will handle this without actually needing to patch the code. And in the end, the init gets replaced before init stops working anyway. You're making things way more complex than a wrapper would do. I'm not a fan of using the words hacking, fragile and not sure for selling an approach; so, why were you suggesting the symlink approach? Don't mix the two mails. I am showing how fragile the solution suggested by Robert is. While you seem to be replying to every mail possible to repeatedly advocate your idea. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 12:12:49 +0200 Robert David robert.david.pub...@gmail.com wrote: On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 4:32 AM, Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. +1 I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. This effectively duplicates data for no real benefit. 1) we waste disk space. 2) if user modifies init.d script, systemd unit is out-of-sync. And the init.d is rewritten (potentially with CONFIG_PROTECT) on next upgrade. 3) if user modifies systemd unit, init.d script is out-of-sync. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, May 26, 2013 at 6:31 AM, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 12:12:49 +0200 Robert David robert.david.pub...@gmail.com wrote: On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman ri...@gentoo.org wrote: Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. This effectively duplicates data for no real benefit. 2) if user modifies init.d script, systemd unit is out-of-sync. And the init.d is rewritten (potentially with CONFIG_PROTECT) on next upgrade. 3) if user modifies systemd unit, init.d script is out-of-sync. To clarify, I was agreeing with the use of a wrapper script - likely symlinked. It would not be compiled/generated at install time, beyond creating the symlink and maybe a conf.d file that pointed to the unit. The eclass would just streamline the installation. As you point out that keeps the configs always in-sync. It also means that if the wrapper script is upgraded to add new features all packages benefit, without needing a re-install. Rich
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On Sun, 26 May 2013 12:23:51 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 9:37 AM, Michał Górny wrote: By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Unit files had been considered when I started exploring the idea, sadly Joost shown me their limitation wouldn't make people life exactly happy. There are always people who are unhappy with anything you'd change. Sometimes it's just about changing the way you see things. I can't tell more without knowing the details though. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. You make clean blueprints, get enough people agreeing with them and implement simple workalike for what you care about. For example logind seems to be the current fad. You're probably right here. But I would have to have the time to work on it, and as you probably noticed I'm engaged in too many projects right now. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. systemd haters, as you name them, could be split in few groups: - those that consider systemd a bad idea because it is a single item with many parts that would break horribly, if your idea is to make it less tightly coupled and with less parts many would consider helping. - those that consider systemd a bad idea because of the force feeding theme started with udev incorporation and continued with logind and such, again if you are creating alternatives the people would help gladly. - those that consider key part of systemd just wrong the limitation in the unit format or path activation as panacea, in that case you have to make clear the scope of your project, you might win few or lose some. You are right again. The outcome would be probably a very modular project which some parts will be used more frequently and others infrequently. But the fact is -- that as far as I see it -- we should be working on replacing all of systemd components. Mixing tightly-coupled parts of systemd with external replacements seems wrong. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. Make it bsd and they would consider helping. I'm not really sure about this. For some of the components probably yes. But the general init replacement / unit runner is not something I'd expect much help with. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? Probably would be better sit down, figure out exactly what you want and see who has interest: E.g. Init-project - portable - must work on non-linux and non-glibc more or less decently - modular- loose coupling of functionality - robust - the core functionality must not crash or remain inconsistent because of libdbus or such often occurring problems unrelated to - compatible - should grok at least a good subset of systemd unit files. Quite a good summary, I'd say. On a side note I really want to know in detail why you loathe openrc with this strength but we can discuss on irc. I'd suspect this is mostly with the growing irritation of systemd haters who spawn endless threads about how they hate anything with 'systemd' name in it. Plus the people who try hard to port the mistakes of OpenRC init scripts to systemd services files. I have my limits, and I'd really prefer doing something useful rather than setting up random things straight, fighting developers and making sure everything keeps working in a semi-sane way. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On 05/26/2013 12:11 PM, Rich Freeman wrote: That means that this whole thing only impacts those who install it, which is the best way to implement something experimental in the first place. +1 I and probably a lot of other people have zero interest in this approach, so we should not be bothered with testing/configuring/using it.
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 12:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 12:12:49 +0200 Robert David robert.david.pub...@gmail.com wrote: On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 4:32 AM, Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. +1 I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. This effectively duplicates data for no real benefit. 1) we waste disk space. Come on, it is 2013, wasting few inodes. I did not got these problems in the old good times with my 386 with 4mb ram and few MB hdd. Those with embedded system will mask many other files, not only systemd units (so they save one inode more with my approach, when need no initscript-wrapper). Users of regular server/desktops/laptops, 10-20 inodes more? They would rather won't use Gentoo with its portage tree or do not compile kernel sources, etc. 2) if user modifies init.d script, systemd unit is out-of-sync. And the init.d is rewritten (potentially with CONFIG_PROTECT) on next upgrade. If someone update iniscript, must be prepared to be outofsync with package version. Thus CONFIG_PROTECT. 3) if user modifies systemd unit, init.d script is out-of-sync. Why someone will modify systemd unit when will be using init.d scripts. And for those few people doing this, the same script as portage use for converting can be used. Robert.
Re: [gentoo-dev] eselect init
On 5/26/13 12:57 PM, Michał Górny wrote: On Sun, 26 May 2013 11:55:24 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 8:43 AM, Michał Górny wrote: On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato lu_z...@gentoo.org wrote: - /sbin/init (or whatever linux currently calls by default with top priority) should be either a symlink to the actual implementation or a wrapper such as our gcc one. I like better the latter since it is overall safer. The former might or might work since linux has some fallback capabilities but hadn't been tested. Increased complexity is never safer. And a wrapper means the additional complexity gets there every boot. And considering how the discussion goes, the wrapper will grow openrc-size in a few months... Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. I need it for my purpose, bb-init syntax isn't the same as sysv. You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. I like to think it normal and the wrapper doesn't need to run every time but only when a switch had been requested. And only if you prefer doing the switch at boot time instead than at shutdown. Did anyone notice already that moving stuff around actually requires rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit of init/RC work. Noticed and known issue, I merely stated which are the options on the plate, keep in mind that init addons people use and we distribute do even more evil stuff. And what will happen if moving the files fail? What if half of configuration belongs to old init, and half to new? And it all happens automagically on boot, on an incomplete system without any console started, without Internet connection established and without any serious mean of help. You can: - consider rolling back - drop to a shell Nothing so terrible. And did you? You keep repeating this and jumping straight to developing work-arounds without even waiting for an answer. And I think William has already spoken that the code supports it. I read the code up to do_exec, given for me it would require have a roundtrip to the efi shell I was hoping those proposing that would do that basic homework =) In any case, I've just tested it. Replaced /sbin/init with a dangling symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh as a fallback. That's all I wanted everybody knows, thanks for helping. OpenRC relies on a few layers of various tools plus a lot of init scripts written by different people. Those init scripts include tasks such as parsing configuration files (well, more of grepping them) and manipulating runtime files. The complexity of OpenRC is the sum of all that. I read it as as complex as the user wants. To make this point cleaner to you: what if the fallback ran systemd instead? As in, init gets broken somehow and kernel falls back to starting systemd on your unprepared OpenRC system. Is this a behavior you'd like? I would expect any sane init would get me at least to their single mode. What I'm telling is: if user uses A as init system (and wanted to switch to B), last thing he'd expect is C being started. Configuration for OpenRC may be long unmaintained, may start services which are not supposed to be started anymore and so on. The safest would be dropping to a shell in your scenario. As I stated from start the switch on boot would work so the wrapper checks a switch had been requested, it knows the current init, that must work since worked the previous boot, the next init, that supposedly should work, does the pivoting, shuffling and such and the next boot it just hands over to the current init. The wrapper could even install and uninstall itself. Again, my object of interest is being able to use bb-init and runit. We're not talking about percentages here. A *single* fragile script is enough to cause trouble. Ten good ones won't revert it. A single fragile script can be fixed I guess, which is the one you have in mind that is concerning? What are you talking about now? I was just saying that *if* you link /sbin/init to systemd, and you're running sysvinit, 'init foo' will be passed through to telinit. But now I see that I was wrong and it actually happened when 'systemctl' was symlinked to 'init'. Nevermind then. In any case, keeping all the tools like 'telinit' should be *enough* to keep the current init running and rebooting. You are focused on systemd, I'm focused on bb-init among the rest, it uses a different syntax for the inittab, so if you want to switch from one or another you either prepare a
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 1:31 PM, Robert David wrote: Come on, it is 2013, wasting few inodes. I did not got these problems in the old good times with my 386 with 4mb ram and few MB hdd. Those with embedded system will mask many other files, not only systemd units (so they save one inode more with my approach, when need no initscript-wrapper). Users of regular server/desktops/laptops, 10-20 inodes more? They would rather won't use Gentoo with its portage tree or do not compile kernel sources, etc. The fact we are already the worst offenders won't make thinking about impacting a little less not that important. System with the problem keep portage in a separate fs. lu
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 12:09:21 +0200 Michał Górny mgo...@gentoo.org wrote: Easy isn't always good. It's not atomic since you can't reboot and because of that I wouldn't call it smooth either. Can't you? How come? Because it expects the init system you boot with to be present. I think that safest way not using wrapper is to stop all services and keep only mounted /, than change things (symlinks,configuration update) and reboot. This can be done two ways. One is hacking into init (RC) reboot procedure. It's fragile, it needs to be fit into the right moment and I'm not sure if all inits will handle this without actually needing to patch the code. And in the end, the init gets replaced before init stops working anyway. You're making things way more complex than a wrapper would do. I'm not a fan of using the words hacking, fragile and not sure for selling an approach; so, why were you suggesting the symlink approach? Don't mix the two mails. Don't read it as mixed, it is not; I take it that you agree with me as you choose not to answer to it. If you meant to advocate your own solution, expanding the other solutions is going to make us forget about what you were suggesting; you're creating your own mixture. I am showing how fragile the solution suggested by Robert is. While you seem to be replying to every mail possible to repeatedly advocate your idea. And I am showing how fragile your expansions to Robert's solution are; thanks for clarifying you meant to point out its fragile, that was not entirely clear from your response and I assumed another intention. We are on the same line here, in fact you have replied more in this sub thread than I did. The wrapper is not my idea; despites my advocation... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 1:15 PM, Michał Górny wrote: I'd suspect this is mostly with the growing irritation of systemd haters who spawn endless threads about how they hate anything with 'systemd' name in it. Plus the people who try hard to port the mistakes of OpenRC init scripts to systemd services files. Here we have a problem, the people that need more flexibility to actually get work done will see that the inflexibility of the unit format will bite them and bite them hard. A simple example is something fairly easy for a runscript and quite annoying for an unit, multiple instances. for openrc you can just symlink using a proper pattern and have the initscript figure the right configuration and which user/chroot use to drop the daemon. for systemd you have to copy and edit since most fields are immutable (some are with special rules). This is something you tend to use a lot for certain kind of services and is made really easy and uniform in openrc while lsb and freebsd tend to have per-script rules. I have my limits, and I'd really prefer doing something useful rather than setting up random things straight, fighting developers and making sure everything keeps working in a semi-sane way. Your dedication is commendable, I do appreciate your help in Gentoo a lot even if we can disagree on some decisions. I know that discussing systemd can get quite annoying since it can easily drift from technical (e.g. my concern regarding dbus) political (systemd as Trojan horse for something else and other strategical concerns), or personal (some people consider Lennart a dangerous/poisonous person) and gets quite easy to mix things up and end up discounting technical concerns by telling that you said this or that just because you hate Lennart. lu
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 12:57:42 +0200 Michał Górny mgo...@gentoo.org wrote: Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. It doesn't need to be in the wrapper, inittab is something read at boot only as far as I am aware and therefore eselect can do it. You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. Did anyone notice already that moving stuff around actually requires rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit of init/RC work. The wrapper only needs to read stuff, I see no reason for it to write stuff. It needs to read which init it needs to kick off, nothing more than that; if more is needed, please elaborate in full detail. And what will happen if moving the files fail? Which files? Since eselect would move them, we would be aware that it failed and could possibly rollback. What if half of configuration belongs to old init, and half to new? Given a rollback, I don't see this happen; unless the rollback fails... And it all happens automagically on boot, on an incomplete system without any console started, without Internet connection established and without any serious mean of help. Barely anything needs to happen on boot, stop adding complexity; the wrapper is meant to be simple, not another init system on its own. People are having way to different ideas about the wrapper, this is not good; I think people should start to express their ideas in documents, same with the symlink solutions. These everything in the wrapper, everything on reboot assumptions are running out of hand. I use systemd for a few months now, and last time I checked openrc boots somehow. But considering the general complexity of it, I wouldn't be much surprised if it failed in funny ways (like not being able to handle automounts properly), caused cruft on the filesystem or even caused *damage*. openrc is *simpler* much *simpler* than systemd, stop with that. [SNIP] To make this point cleaner to you: what if the fallback ran systemd instead? [SNIP] Why should the fallback be different from what stage3 provides? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 13:45:43 +0200 Tom Wijsman tom...@gentoo.org wrote: On Sun, 26 May 2013 12:09:21 +0200 Michał Górny mgo...@gentoo.org wrote: Easy isn't always good. It's not atomic since you can't reboot and because of that I wouldn't call it smooth either. Can't you? How come? Because it expects the init system you boot with to be present. And it is present. It's just the symlink what differs. The symlink should be used just to boot the init and for nothing more. The booted init should be able to find itself. If it isn't, it's the init's what needs to be fixed. Really. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 13:40:03 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 12:57 PM, Michał Górny wrote: Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. I need it for my purpose, bb-init syntax isn't the same as sysv. Then you need to use a different file. Feel free to rename either inittab but don't even think of switching files like this. You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. I like to think it normal and the wrapper doesn't need to run every time but only when a switch had been requested. And only if you prefer doing the switch at boot time instead than at shutdown. Well, that makes it a bit less destructive. Though I still don't like the idea. And what will happen if moving the files fail? What if half of configuration belongs to old init, and half to new? And it all happens automagically on boot, on an incomplete system without any console started, without Internet connection established and without any serious mean of help. You can: - consider rolling back - drop to a shell Nothing so terrible. Sounds like an initramfs... What I'm telling is: if user uses A as init system (and wanted to switch to B), last thing he'd expect is C being started. Configuration for OpenRC may be long unmaintained, may start services which are not supposed to be started anymore and so on. The safest would be dropping to a shell in your scenario. As I stated from start the switch on boot would work so the wrapper checks a switch had been requested, it knows the current init, that must work since worked the previous boot, the next init, that supposedly should work, does the pivoting, shuffling and such and the next boot it just hands over to the current init. It all depends on how it is implemented. If we decide not to touch /sbin/init, then sysvinit will be the effective fallback at some earlier or later point, depending on what will fail. This is what I really dislike. We're not talking about percentages here. A *single* fragile script is enough to cause trouble. Ten good ones won't revert it. A single fragile script can be fixed I guess, which is the one you have in mind that is concerning? You could've asked me that when I was still using OpenRC. I don't really want to grep the 40 scripts right now, and I don't think I have the worse cases installed here. What are you talking about now? I was just saying that *if* you link /sbin/init to systemd, and you're running sysvinit, 'init foo' will be passed through to telinit. But now I see that I was wrong and it actually happened when 'systemctl' was symlinked to 'init'. Nevermind then. In any case, keeping all the tools like 'telinit' should be *enough* to keep the current init running and rebooting. You are focused on systemd, I'm focused on bb-init among the rest, it uses a different syntax for the inittab, so if you want to switch from one or another you either prepare a least-action script that switch the inittab on reboot or a first-action script that does that on boot. For your needs probably just pivoting a symlink should work almost fine, as long your stay sysvinit compatible, yet doing that as early init or as post kill-all should work better even in your case. Well, you're transforming a simple idea with potentially relatively wide audience into a horror story with a single user. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 12:01:19 +0200 Robert David robert.david.pub...@gmail.com wrote: Newer say that wrapper will grow openrc size, and also dont know why it would be bad. That's what I'd like to know from him, I was quoting both of you, I really dont know how many user will switch inits and how many of them will do this regularly. Users that would like to compare things, users that are bothered by one init system and try to try an alternative one; developers that want to test both init scripts and service units and thus need to change often, people that would want a specific init system but haven't found out how to switch properly to it yet. I think there are more than a hand full. But the wrapper will be executed every boot. So even a tiny mistake can produce booting problems even for those who did not wanted to change anything in init process. One would properly test the wrapper, perhaps even have multiple members of arch teams test it, before bringing this out to the user base; it's a very critical matter and we can indeed not afford a mistake here. That being said, once the wrapper is in place and works; I don't think we need to touch it often, it's just a wrapper after all. Do other wrappers, desktop files and files of similar nature we use around Gentoo change often; I think not. On the other hand mistake in some system process will affect only those who would actually switching. It is only calculation of possible risks. If you do risk assessment, you should count in all risks; that therefore also means to take maintainability into account. See my other mail about what it takes to step away from a loosely coupled approach. I also did not say it must be done the reboot way I mentioned, this is only and different point what can be though about. And we're thinking it through, I don't see why you mention this; I can understand that you don't necessarily stand behind it though, that's OK. I'd rather have a clean wrapper that just works than an unclean way to cover the reboot madness that comes along; forcing a reboot, really? I do not see point not forcing reboot when I'm switching init, or let say suggesting. When you update your kernel config, rebuild and install you also can stay working, but you have to be prepared to have nonworking modules that was not inserted before. My point was that with a wrapper you don't need to force this; the modules problem is irrelevant to this discussion, I don't see any problem in that light with the approaches we are discussing here. PS: If this message ends up in a separate thread, it's because I'm forwarding it from my Sent mail because there was no reply-to present. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On 5/26/13 2:08 PM, Michał Górny wrote: You could've asked me that when I was still using OpenRC. I don't really want to grep the 40 scripts right now, and I don't think I have the worse cases installed here. Worth investigation, not by you, but those that loathe systemd should have a look and see if they could fix some. For your needs probably just pivoting a symlink should work almost fine, as long your stay sysvinit compatible, yet doing that as early init or as post kill-all should work better even in your case. Well, you're transforming a simple idea with potentially relatively wide audience into a horror story with a single user. Hopefully not =) I just stated what's the problem and the possible solutions. As said from start I want the whole thing to be an opt-in and to cause the least amount of disruption on current setups. Patching sysvinit and bb-init to accept a -c filename would make the whole thing much simpler if we pick a wrapper solution for my most complex case. lu
Re: [gentoo-dev] eselect init
On Sat, May 25, 2013 21:55, Tom Wijsman wrote: On Sat, 25 May 2013 21:09:47 +0200 J. Roeleveld jo...@antarean.org wrote: How will the stop/start part of services/init-scripts/... be done? Not sure what you mean here; if you keep init function the same as the init you boot with, this should continue to work. As an example. Lets say I want to test a new init-system. To do this, I follow the (still to be written) guide on eselect init and boot into new-and-shiny-init-system. I am still used to stopping/starting services using /etc/init.d/service start/stop And using the rc command to add/remove services from the runlevel(s). If I then, accidentally, type /etc/init.d/xyz start when xyz hasn't been started by any means yet. What will happen? I would assume that openrc will try to start xyz? This is, I believe, something that could cause issues as dependencies might also try to start and I then have a service running not managed by the new-and-shiny-init-system that I was testing. I am assuming that should be for the user to keep in mind, but will it be possible to add something that will make init.d-scripts not work when systemd is running and unit-files not work when systemd is not running? They currently just bail out with bogus errors as far as I am aware. # /etc/init.d/ntpd start ntpd | * WARNING: ntpd is already starting # /etc/init.d/ntpd stop ntpd | * ERROR: ntpd stopped by something else See above, what about if ntpd wasn't running yet? hooks on reboot are still needed for more complex ones. Which complex cases would these hooks be needed on? I think one of these would be the stopping/starting of services (see above) No, if you keep the init system the same as the one you boot with there should be no problems. See above, what about trying to start services using the method of the not-running init? [[ Below is my ONLY remark on that, please feel free to mentally paste it as a response any email trying to explain why it's important to reduce the boottime ]] My intention was not to advocate optimizing boot times; I know, that bit was meant generic, not just as a reply to you. as a kernel maintainer / developer I need to test new releases, run git bisects, do Nouveau reclocking work. I really need this, the average person that keeps his PC running, not so much; I care for it because I can't wait 2 minutes, not because I think it's shiny to have such a short boot... PS: I'm also a mobile laptop user that no longer has a battery. :/ I believe you can still use hibernate there? :) -- Joost
Re: [gentoo-dev] eselect init
On Sat, 25 May 2013 21:55:20 +0200 Tom Wijsman tom...@gentoo.org wrote: On Sat, 25 May 2013 21:09:47 +0200 J. Roeleveld jo...@antarean.org wrote: +1 for wrapper, from my understanding, symlinks for init-systems can't be altered on a running system without risking strange behaviour. Exactly... # shutdown -h now The system is going down for system halt NOW!s/1) (Sat May 25 21:25:41 2013): Excess arguments. I don't know what is the state of your system when testing this but on my system /sbin/telinit is a symlink to /sbin/init. So replacing the latter also replaces telinit with something unexpected. Of course, the solution is to make telinit point to the real sysvinit executable. Not sure how well it will reboot then, however. It may be necessary to also change 'halt' to use 'telinit' if it uses 'init' directly. I am assuming that should be for the user to keep in mind, but will it be possible to add something that will make init.d-scripts not work when systemd is running and unit-files not work when systemd is not running? They currently just bail out with bogus errors as far as I am aware. # /etc/init.d/ntpd start ntpd | * WARNING: ntpd is already starting # /etc/init.d/ntpd stop ntpd | * ERROR: ntpd stopped by something else I think we fixed this already... well, not exactly this because openrc used to try to actually start stuff. I would consider this a regression since it had explanatory error messages. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On Sun, 26 May 2013 13:59:34 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 1:15 PM, Michał Górny wrote: I'd suspect this is mostly with the growing irritation of systemd haters who spawn endless threads about how they hate anything with 'systemd' name in it. Plus the people who try hard to port the mistakes of OpenRC init scripts to systemd services files. Here we have a problem, the people that need more flexibility to actually get work done will see that the inflexibility of the unit format will bite them and bite them hard. A simple example is something fairly easy for a runscript and quite annoying for an unit, multiple instances. for openrc you can just symlink using a proper pattern and have the initscript figure the right configuration and which user/chroot use to drop the daemon. You need to name a unit with @ suffix, like openvpn@.service: $ cat /etc/systemd/system/openvpn@.service [Service] Type=simple ExecStart=/usr/sbin/openvpn --user openvpn --group openvpn --cd /etc/openvpn --chroot /var/run/openvpn --config %I.conf feel free to sprinkle %i (and others) for templating. and symlink it as you like. openvpn@foo.service (or openvpn@foo) will be direct analogue to openvpn.foo. (+ foo.service.d with the same(?) override semantics) for systemd you have to copy and edit since most fields are immutable (some are with special rules). .include /path/to/unit OverrideedField = OverridedValue will not help here, right? -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 14:59:28 +0200 J. Roeleveld jo...@antarean.org wrote: As an example. Lets say I want to test a new init-system. [SNIP] If I then, accidentally, type /etc/init.d/xyz start when xyz hasn't been started by any means yet. What will happen? I would assume that openrc will try to start xyz? As I said before: They currently just bail out with bogus errors as far as I am aware. # /etc/init.d/ntpd start ntpd | * WARNING: ntpd is already starting # /etc/init.d/ntpd stop ntpd | * ERROR: ntpd stopped by something else See above, what about if ntpd wasn't running yet? ntpd isn't running on my system and wasn't when I did that. No, if you keep the init system the same as the one you boot with there should be no problems. See above, what about trying to start services using the method of the not-running init? The same, feel free to emerge systemd and try to start a service; I expect this to bail out since its dependencies aren't started, for its dependencies to start the init system itself should be in use. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 15:15:26 +0200
Michał Górny mgo...@gentoo.org wrote:
Cc: tom...@gentoo.org
Please don't CC me, this causes duplicate mails; one of both does not
include reply-to. Nobody else that has responded to me did this before.
Unless you can give me an awesome procmail rule to process these... :)
I don't know what is the state of your system when testing this but on
my system /sbin/telinit is a symlink to /sbin/init. So replacing
the latter also replaces telinit with something unexpected.
I did something like `mv /sbin/init{,.bak} ; mv systemd /sbin/init`
Of course, the solution is to make telinit point to the real sysvinit
executable. Not sure how well it will reboot then, however. It may be
necessary to also change 'halt' to use 'telinit' if it uses 'init'
directly.
Currently I use `systemctl reboot` and `systemctl poweroff`, I
actually have no idea how to make telinit work again with systemd.
# /etc/init.d/ntpd start
ntpd | * WARNING: ntpd is already starting
# /etc/init.d/ntpd stop
ntpd | * ERROR: ntpd stopped by something else
I think we fixed this already... well, not exactly this because openrc
used to try to actually start stuff. I would consider this a
regression since it had explanatory error messages.
The stop error is reasonable I think, the start error is indeed odd.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/05/13 03:08 PM, Matthew Thode wrote: On 05/25/13 05:25, Peter Stuge wrote: Luca Barbato wrote: - init gets effectively switched only at boot/reboot Please not on reboot, because an unclean shutdown shouldn't leave the system in limbo. On boot could work, except that it does add more steps (= more fragility) to the boot process, which I think everyone wants to avoid. I would actually expect the change to take effect immediately. //Peter the final action before / is remouted ro at shutdown would make sense to me. It's either that or first action at boot. First action at boot, without an initramfs, is too late isn't it? The kernel has already launched init at this point. Also, relying on something at shutdown is going to be problematic too -- openrc and systemd (and whatever others) all need the functionality to do this built into their scripts, and cases of dirty shutdowns are not going to be handled well. The only way I can think of that this is going to work, every time, reliably, is if it was done within an initramfs and therefore prior to the start of actual init (ie, initramfs would read a config file to determine what init-selector to run, calls the init-selector actions, and then exec's that init -- that config file could be eselect-controlled or just edited) And that brings back in the whole initramfs-required flamewar -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGiGIMACgkQ2ugaI38ACPBw+gD6A6F5DF6fTFYibbpBjueg1rw1 SL/zUYRomTXDrfhqbDUA/3YxUCAeXrX8dDAlQKbomWnVCG9gKrZObOF5lFo/MXZs =GXEk -END PGP SIGNATURE-
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 3:35 PM, Sergei Trofimovich wrote: On Sun, 26 May 2013 13:59:34 +0200 Luca Barbato lu_z...@gentoo.org wrote: You need to name a unit with @ suffix, like openvpn@.service: $ cat /etc/systemd/system/openvpn@.service [Service] Type=simple ExecStart=/usr/sbin/openvpn --user openvpn --group openvpn --cd /etc/openvpn --chroot /var/run/openvpn --config %I.conf feel free to sprinkle %i (and others) for templating. Feel free to check which fields accept %expansions and which do not, last time I heard some fields do not. If it had been fixed I'm glad. lu
Re: [gentoo-dev] eselect init
On Sun, May 26, 2013 at 10:07 AM, Tom Wijsman tom...@gentoo.org wrote: On Sun, 26 May 2013 15:15:26 +0200 Michał Górny mgo...@gentoo.org wrote: Cc: tom...@gentoo.org Please don't CC me, this causes duplicate mails; one of both does not include reply-to. Nobody else that has responded to me did this before. Unless you can give me an awesome procmail rule to process these... :) :0 Wh: msgid.lock | formail -D 8192 msgid.cache :0 a: .duplicates/new (or /dev/null as you prefer) I'm sure it isn't perfect, but I've been running it for years. Between lists and aliases I'd be buried in dups otherwise. Apologies for the OT, but I figured this was useful, and you did ask... Rich
Re: [gentoo-dev] eselect init
On 5/26/13 1:58 PM, Tom Wijsman wrote: On Sun, 26 May 2013 12:57:42 +0200 Michał Górny mgo...@gentoo.org wrote: Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. It doesn't need to be in the wrapper, inittab is something read at boot only as far as I am aware and therefore eselect can do it. Apparently it is read when you switch runlevel as well. lu
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/05/13 07:40 AM, Luca Barbato wrote: On 5/26/13 12:57 PM, Michał Górny wrote: You are telling me that a wrapper, a thing that gets executed *every* boot needs to do some random magic to know which init system was in use and which one is supposed to be in use, and then conditionally move around configuration files necessary for it to run. This is just *INSANE*. I like to think it normal and the wrapper doesn't need to run every time but only when a switch had been requested. And only if you prefer doing the switch at boot time instead than at shutdown. The way it's being proposed (and please correct me if i'm wrong), the wrapper is a direct replacement binary (small C program) for all init systems, and would based on some configuration file or whatnot determine and exec the init system it's supposed to -- and make any other necessary changes too, such as switching /etc/inittab) I don't know (outside of a script in the initramfs) how this would otherwise be handled to cover all cases. I am curious though, if you see a way to do this otherwise, what the implementation would look like? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGiIxAACgkQ2ugaI38ACPDrbAD/exZAI4utNuOBAMzdkeYj8JgB lmeOg+G892g4yYMa6cIBALEQMH3bliQ0hF3HEtJezdbzG4/XkaEdGIjM+gscxF79 =9J3a -END PGP SIGNATURE-
Re: [gentoo-dev] eselect init
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/05/13 08:59 AM, J. Roeleveld wrote: On Sat, May 25, 2013 21:55, Tom Wijsman wrote: On Sat, 25 May 2013 21:09:47 +0200 J. Roeleveld jo...@antarean.org wrote: How will the stop/start part of services/init-scripts/... be done? Not sure what you mean here; if you keep init function the same as the init you boot with, this should continue to work. As an example. Lets say I want to test a new init-system. To do this, I follow the (still to be written) guide on eselect init and boot into new-and-shiny-init-system. I am still used to stopping/starting services using /etc/init.d/service start/stop And using the rc command to add/remove services from the runlevel(s). If I then, accidentally, type /etc/init.d/xyz start when xyz hasn't been started by any means yet. What will happen? I would assume that openrc will try to start xyz? This is, I believe, something that could cause issues as dependencies might also try to start and I then have a service running not managed by the new-and-shiny-init-system that I was testing. Point #1 - openrc isn't init -- 'eselect init' or w/e is not necessarily going to be the same as 'eselect rc-system'. It's unlikely that you'll want to use another rc system if using systemd for your init, but that doesn't mean you can't. Point #2 - yes, this can be an issue and I believe it's already being worked on separately; WilliamH has mentioned issues like this more than once on irc, at least, although I don't know if he's implemented any solution(s). This bit should go into a separate thread or bug, and not be considered part of the overall 'eselect init' solution imo. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGiIiQACgkQ2ugaI38ACPA7dwD/Y6IJo+/j2Ho4p1bM8mGMt7E8 ZglL7SvNS7g/90K6n1gA/37F0u5v2gzIoSTVi6uEmyhcPMW/2I2vr+YRv0rALO8S =PuVY -END PGP SIGNATURE-
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On 26 May 2013 18:04, Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 3:43 AM, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 15:23:44 +0800 Ben de Groot yng...@gentoo.org wrote: Where is this policy documented? Nowhere, I think. I've seen it coming in the late thread, looked common sense enough to me. If it is to be documented, I think we should document it in a more general fashion. To cover all stuff like completions, logrotate and so on. As others have already pointed out, we are an organization, not a CPU. We can't make EVERYTHING a rule, and devs should act in a cooperative manner so that this remains the case. Sure, this can be made into a policy, and if things get out of hand I'm sure it will be. I'm not quite sure I see the need yet, as we don't have an example yet of a maintainer not cooperating with the systemd team on the installation of init files (in the present example Ben isn't actually a maintainer, since he stepped down). In packages I maintain, I will not be adding any systemd related files. All bug reports requesting such additions will be closed as an upstream matter. If Ben wants to boycott systemd by not maintaining any packages that support it, that is his choice. I just suspect that the end result of that will be that he'll end up not maintaining much of anything. I'd hate to see that happen, as it would be a loss for Gentoo. But, frankly, letting any one person dictate the direction of the entire distro by essentially threatening to quit would be worse. Gentoo is evolving in directions I do not agree with. I am feeling less and less at home here. More and more often it seems I am the minority voice of protest. I am not enjoying this role, and increasingly the thought arises that I should just get out of people's way and find another place that is closer to my ideas of what a distro should be. Gentoo is about choice - and the nature of choice is that most of the choices it supports are ones that you wouldn't personally make. We do a reasonably good job letting everybody have their cake and eat it too. However, it really isn't an appropriate distro for absolute purists of almost any kind - it reeks of compromise. We package proprietary software (we don't redistribute the copyrighted parts), we more-or-less run on Windows/OSX, we support that X32 alternate architecture that some believe has no useful purpose, and so on. If you really want to influence the battle of the init implementations, then write code, not emails. I am not a programmer, I am a simple package maintainer. Maybe that is a wrapper that allows OpenRC to support systemd units. Maybe that is more functionality for OpenRC. Maybe it is something else. However, trying to influence things by just spitting into the wind isn't going to do much but get your face dirty. Sure, devs can quit, but that isn't just a loss for Gentoo. Frankly if your main goal in life is to avoid systemd then you're better off supporting Gentoo which is likely to support that option nearly forever far better than any other distro. If forcing Gentoo package maintainers to add systemd support to packages they maintain is your idea of the best option to avoid systemd, then I respectfully disagree. Obviously I have better (and more fun) things to do. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 16:52:27 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 1:58 PM, Tom Wijsman wrote: On Sun, 26 May 2013 12:57:42 +0200 Michał Górny mgo...@gentoo.org wrote: Switch inittab? Now you added really dangerous behavior to the wrapper code. I can hardly even express this in words. It doesn't need to be in the wrapper, inittab is something read at boot only as far as I am aware and therefore eselect can do it. Apparently it is read when you switch runlevel as well. Ouch, that indeed makes it impossible for eselect to do this and makes the wrapper more complex; unless there is a sane way to on reboot, but then we would be implementing this in too many places. I think some of the other suggestions made here also don't take this into account. Thanks for mentioning. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/26/2013 11:21 AM, Ben de Groot wrote: On 26 May 2013 18:04, Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 3:43 AM, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 15:23:44 +0800 Ben de Groot yng...@gentoo.org wrote: Where is this policy documented? Nowhere, I think. I've seen it coming in the late thread, looked common sense enough to me. If it is to be documented, I think we should document it in a more general fashion. To cover all stuff like completions, logrotate and so on. As others have already pointed out, we are an organization, not a CPU. We can't make EVERYTHING a rule, and devs should act in a cooperative manner so that this remains the case. Sure, this can be made into a policy, and if things get out of hand I'm sure it will be. I'm not quite sure I see the need yet, as we don't have an example yet of a maintainer not cooperating with the systemd team on the installation of init files (in the present example Ben isn't actually a maintainer, since he stepped down). In packages I maintain, I will not be adding any systemd related files. All bug reports requesting such additions will be closed as an upstream matter. If Ben wants to boycott systemd by not maintaining any packages that support it, that is his choice. I just suspect that the end result of that will be that he'll end up not maintaining much of anything. I'd hate to see that happen, as it would be a loss for Gentoo. But, frankly, letting any one person dictate the direction of the entire distro by essentially threatening to quit would be worse. Gentoo is evolving in directions I do not agree with. I am feeling less and less at home here. More and more often it seems I am the minority voice of protest. I am not enjoying this role, and increasingly the thought arises that I should just get out of people's way and find another place that is closer to my ideas of what a distro should be. Gentoo is about choice - and the nature of choice is that most of the choices it supports are ones that you wouldn't personally make. We do a reasonably good job letting everybody have their cake and eat it too. However, it really isn't an appropriate distro for absolute purists of almost any kind - it reeks of compromise. We package proprietary software (we don't redistribute the copyrighted parts), we more-or-less run on Windows/OSX, we support that X32 alternate architecture that some believe has no useful purpose, and so on. If you really want to influence the battle of the init implementations, then write code, not emails. I am not a programmer, I am a simple package maintainer. Maybe that is a wrapper that allows OpenRC to support systemd units. Maybe that is more functionality for OpenRC. Maybe it is something else. However, trying to influence things by just spitting into the wind isn't going to do much but get your face dirty. Sure, devs can quit, but that isn't just a loss for Gentoo. Frankly if your main goal in life is to avoid systemd then you're better off supporting Gentoo which is likely to support that option nearly forever far better than any other distro. If forcing Gentoo package maintainers to add systemd support to packages they maintain is your idea of the best option to avoid systemd, then I respectfully disagree. Perhaps this was covered already, but how exactly did this one file, added by your co-maintainer, hurt you? Did it cause additional bugs? Did it break a working ebuild? Did it kill your cat? It would seem to me that the co-maintainer (a person who cares that some users are interested in systemd enough to add one file to the package) made the package support a slightly wider range of systems (gentoo is about choice) and this affects you in exactly no way. What am I missing here? Are you just trying to force your will on others or do you have an actual issue caused by this commit? It is not for us developers to force one way on the users, gentoo is supposed to be about choice, your co-maintainer chose to support systemd, an action which as far as I can see didn't harm you, and helped some users. This has been a very long thread for something I don't get at all. Please, seriously, what am I missing here? - -Zero Obviously I have better (and more fun) things to do. -- Cheers, Ben | yngwin Gentoo developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRojUxAAoJEKXdFCfdEflKNXUQAJufMr9HC/7KPLQEWxZG+LH0 kWzrzSjH9I5OLNhTxuVs3IuMupeHL2BPA2oXZV/hj/NKhJid8FXKlNRB9PCuE6qq ClrnSLuYcdabTNzUmePM+h0CEU5FMkA4Z3GJiT2GtB9fv8CbnjcbuqZAYK4zYupT B8O61/o/uYCYPEgekqi/vU3xOtPA+wzzwXILV4Kf/YNb9A/z/SyIIsJv4JN2qvSm UYCe5Q4h7JqUTz0DzL3lVFLhTFdvCWPErP5Okrn1yk8cCL5878ixDkQBm5dL53NH NNu3EPPhvnljV6Ja1CEAOKmORp2Ry+DDSbYUhx0SK0g/fzo4JQP1TD/IraicQExV
Re: [gentoo-dev] eselect init
On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote: Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Please explain why this wrapper would need to switch inittab. Inittab is only used by sysvinit and has no uses in any other init system. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote: On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote: Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Please explain why this wrapper would need to switch inittab. Inittab is only used by sysvinit and has no uses in any other init system. Ok, sorry, I was wrong in my previous msg, now I see that bb-init has its own inittab with a different format. How about patching bb-init so that it can handle a sysvinit inittab? William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
On Sun, 26 May 2013 11:48:30 -0500 William Hubbs willi...@gentoo.org wrote: On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote: On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote: Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Please explain why this wrapper would need to switch inittab. Inittab is only used by sysvinit and has no uses in any other init system. Ok, sorry, I was wrong in my previous msg, now I see that bb-init has its own inittab with a different format. How about patching bb-init so that it can handle a sysvinit inittab? Er, isn't that too far to diverge from upstream? If we're to patch something, I'd rather patch it to use a different path. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On Sun, May 26, 2013 at 9:15 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: Perhaps this was covered already, but how exactly did this one file, added by your co-maintainer, hurt you? Did it cause additional bugs? Did it break a working ebuild? Did it kill your cat? It would seem to me that the co-maintainer (a person who cares that some users are interested in systemd enough to add one file to the package) made the package support a slightly wider range of systems (gentoo is about choice) and this affects you in exactly no way. What am I missing here? Are you just trying to force your will on others or do you have an actual issue caused by this commit? It is not for us developers to force one way on the users, gentoo is supposed to be about choice, your co-maintainer chose to support systemd, an action which as far as I can see didn't harm you, and helped some users. This has been a very long thread for something I don't get at all. Please, seriously, what am I missing here? Thanks for asking this. After reading the 34 emails in this thread, I still have this question as well.
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
Am Sonntag, 26. Mai 2013, 18:15:46 schrieb Rick Zero_Chaos Farina: Perhaps this was covered already, but how exactly did this one file, added by your co-maintainer, hurt you? Did it cause additional bugs? Did it break a working ebuild? Did it kill your cat? +1 -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] eselect init
On Sun, May 26, 2013 at 06:55:45PM +0200, Michał Górny wrote: On Sun, 26 May 2013 11:48:30 -0500 William Hubbs willi...@gentoo.org wrote: On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote: On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote: Openrc is small, but the wrapper really needs to know which is which and worst case switch inittab. Please explain why this wrapper would need to switch inittab. Inittab is only used by sysvinit and has no uses in any other init system. Ok, sorry, I was wrong in my previous msg, now I see that bb-init has its own inittab with a different format. How about patching bb-init so that it can handle a sysvinit inittab? Er, isn't that too far to diverge from upstream? If we're to patch something, I'd rather patch it to use a different path. From what I just read, the difference is that busybox init ignores the runlevels specified in sysvinit inittab. I guess it isn't an error for the runlevels to be there, it just doesn't do anything with them. Luca, If that's the only difference, do we really need to modify the inittab at all? William signature.asc Description: Digital signature
Re: [gentoo-dev] eselect init
On 5/27/13 12:58 AM, William Hubbs wrote: From what I just read, the difference is that busybox init ignores the runlevels specified in sysvinit inittab. Nope, it interprets the numbers in a different way. If that's the only difference, do we really need to modify the inittab at all? Yes, I tested it first and got the whole system unworkable, one single mode later I baked something to get at least the minimal functionality, supporting our xdm script properly required some more effort I hadn't time to pour that day. lu
Re: [gentoo-dev] eselect init
On 5/26/13 4:13 PM, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/05/13 03:08 PM, Matthew Thode wrote: On 05/25/13 05:25, Peter Stuge wrote: Luca Barbato wrote: - init gets effectively switched only at boot/reboot Please not on reboot, because an unclean shutdown shouldn't leave the system in limbo. On boot could work, except that it does add more steps (= more fragility) to the boot process, which I think everyone wants to avoid. I would actually expect the change to take effect immediately. //Peter the final action before / is remouted ro at shutdown would make sense to me. It's either that or first action at boot. First action at boot, without an initramfs, is too late isn't it? bootchart2 shows that is quite possible and working fine for it =) The current mode to switch init manually for my use-case is to drop to single user, do your stuff, reboot or reload init if the init or the operating system supports it. Drop to single user is quite the same as rebooting anyway. lu
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-05-26 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-05-26 23h59 UTC. Removals: net-im/ktp-contact-applet 2013-05-21 18:29:14 johu net-im/ktp-presence-applet 2013-05-21 18:30:43 johu games-action/heavygear2 2013-05-25 07:44:43 yngwin media-libs/vflib2013-05-25 08:02:42 yngwin app-text/tex-guy2013-05-25 08:04:07 yngwin Additions: net-dns/pdns-ldap-backend 2013-05-21 06:20:57 dev-zero sci-chemistry/numbat2013-05-21 10:55:38 jlec app-misc/zygrib 2013-05-21 12:12:54 mschiff media-gfx/assimp2013-05-22 06:56:32 slis dev-lua/lpeg2013-05-22 08:15:06 radhermit dev-lua/luajson 2013-05-22 08:20:46 radhermit dev-libs/kqoauth2013-05-22 08:50:46 maksbotan dev-python/sparql-wrapper 2013-05-22 10:02:33 patrick sci-chemistry/parassign 2013-05-22 11:12:33 jlec dev-python/jsmin2013-05-22 16:00:38 idella4 x11-wm/goomwwm 2013-05-22 21:59:24 jer app-misc/evemu 2013-05-23 22:47:19 radhermit app-leechcraft/lc-krigstask 2013-05-24 15:16:42 pinkbyte app-leechcraft/lc-laughty 2013-05-24 15:21:28 pinkbyte app-leechcraft/lc-mellonetray 2013-05-24 15:22:50 pinkbyte app-leechcraft/lc-sysnotify 2013-05-24 15:23:51 pinkbyte dev-ml/custom_printf2013-05-24 16:38:56 aballier dev-ml/zero 2013-05-24 17:02:47 aballier x11-themes/smplayer-skins 2013-05-25 07:41:29 yngwin net-libs/libhackrf 2013-05-25 15:28:15 zerochaos app-misc/vzstats2013-05-25 18:14:22 maksbotan dev-haskell/attoparsec 2013-05-26 04:00:37 gienah dev-haskell/case-insensitive2013-05-26 04:01:43 gienah media-plugins/vdr-cdplayer 2013-05-26 16:00:41 hd_brummy -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-im/ktp-contact-applet,removed,johu,2013-05-21 18:29:14 net-im/ktp-presence-applet,removed,johu,2013-05-21 18:30:43 games-action/heavygear2,removed,yngwin,2013-05-25 07:44:43 media-libs/vflib,removed,yngwin,2013-05-25 08:02:42 app-text/tex-guy,removed,yngwin,2013-05-25 08:04:07 Added Packages: net-dns/pdns-ldap-backend,added,dev-zero,2013-05-21 06:20:57 sci-chemistry/numbat,added,jlec,2013-05-21 10:55:38 app-misc/zygrib,added,mschiff,2013-05-21 12:12:54 media-gfx/assimp,added,slis,2013-05-22 06:56:32 dev-lua/lpeg,added,radhermit,2013-05-22 08:15:06 dev-lua/luajson,added,radhermit,2013-05-22 08:20:46 dev-libs/kqoauth,added,maksbotan,2013-05-22 08:50:46 dev-python/sparql-wrapper,added,patrick,2013-05-22 10:02:33 sci-chemistry/parassign,added,jlec,2013-05-22 11:12:33 dev-python/jsmin,added,idella4,2013-05-22 16:00:38 x11-wm/goomwwm,added,jer,2013-05-22 21:59:24 app-misc/evemu,added,radhermit,2013-05-23 22:47:19 app-leechcraft/lc-krigstask,added,pinkbyte,2013-05-24 15:16:42 app-leechcraft/lc-laughty,added,pinkbyte,2013-05-24 15:21:28 app-leechcraft/lc-mellonetray,added,pinkbyte,2013-05-24 15:22:50 app-leechcraft/lc-sysnotify,added,pinkbyte,2013-05-24 15:23:51 dev-ml/custom_printf,added,aballier,2013-05-24 16:38:56 dev-ml/zero,added,aballier,2013-05-24 17:02:47 x11-themes/smplayer-skins,added,yngwin,2013-05-25 07:41:29 net-libs/libhackrf,added,zerochaos,2013-05-25 15:28:15 app-misc/vzstats,added,maksbotan,2013-05-25 18:14:22 dev-haskell/attoparsec,added,gienah,2013-05-26 04:00:37 dev-haskell/case-insensitive,added,gienah,2013-05-26 04:01:43 media-plugins/vdr-cdplayer,added,hd_brummy,2013-05-26 16:00:41 Done.
