Bug#727708: SystemD
On 12/02/14 19:43, Brandon wrote: I have been a long time debian user. Please do not implement systemd. I don't want to switch to another OS but I will. For the jessie release, it should be possible to uninstall systemd on GNU/Linux and still have most functionality. The non-Linux ports are likely going to work that way, which means the init scripts will have been already tested for this. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fbd56a.4000...@pyro.eu.org
Bug#727708: call for votes on default Linux init system for jessie
On 08/02/14 23:24, Steve Langasek wrote: There has never been anything blocking any Debian developer from doing work on improving the integration of systemd in Debian, on their own packages or on the packages of others. OTOH I'm eagerly awaiting the TC's decision[s] because it will likely influence the direction of the non-Linux ports. If Upstart had won somehow, most people working on GNU/kFreeBSD seemed willing to adopt it on those grounds. But it no longer seems the likely choice for GNU/Linux. And assuming systemd wins, a policy decision on dependencies and level of coupling may lead to ports either supporting or dropping certain packages, or a whole desktop environment. IMHO it was a little frustrating that Ian's ballot couldn't go ahead last week and reach a consensus on both issues. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: Call for votes on init system resolution
Hi, Thank you both for inviting comments on this from a porter's POV. Steve Langasek vor...@debian.org writes: - Packages in jessie must retain compatibility with sysvinit startup interfaces (i.e., init scripts in /etc/init.d). This would be greatly reassuring; if adopting systemd, this is IMHO the primary concern for the non-Linux ports (and of using other init systems on GNU/Linux). I don't know how willing maintainers are to accept it, but I assume there are multiple reasons to still maintain sysvinit scripts in jessie: 1. a smooth upgrade process 2. ease of backporting, perhaps 3. for the benefit of using other init systems on GNU/Linux 4. for the benefit of non-systemd ports If 4. had been the only reason, I think porters would accept some number of packages becoming linux-any, to avoid burdening their maintainers unreasonably. (Similarly, we may yet be unable to support packages requiring logind, if nobody ports it). On 08/02/14 20:38, Russ Allbery wrote: Package maintainers are strongly encouraged to merge any contributions for support of init systems other than the Linux default, and to add that support themselves if they're willing and capable of doing so. In particular, package maintainers should put a high priority on merging changes to support any init system which is the default on one of Debian's non-Linux ports. A quick poll on the debian-bsd@ list showed that if Upstart had been chosen as default on GNU/Linux, it would have been favoured on GNU/kFreeBSD, too. (BTW I'm extremely thankful to Dimitri and any others at Canonical who made efforts to port it). But otherwise, given systemd as default, the overall preference was to keep using sysvinit for jessie (which surprised me, as this wasn't my own preference). In second place would be OpenRC (4:0 over Upstart, again surprising as it is a reversal of the above). https://lists.debian.org/debian-bsd/2014/01/msg00300.html A draft statement on the debian-hurd@ list asks that sysvinit scripts remain in place, and proposes that GNU/Hurd porters help maintain them, being keen to adopt OpenRC later: https://lists.debian.org/debian-hurd/2014/01/msg00051.html This actually sounds beneficial all around. If porters were only writing OpenRC runscripts, that wouldn't help much with the need to anyway keep the sysvinit scripts maintained: work that benefits GNU/Linux users too. What I also like about this is that non-default init systems will all have plenty of time to evolve (or appear, or disappear); I'm hopeful that for jessie+1 the successor to sysvinit will have become obvious. So Russ's paragraph above, referring to the default init system on non-Linux ports - if that is going to be sysvinit - would have effectively the same meaning as the following: For the jessie release, all packages that currently support being run under sysvinit should continue to support sysvinit unless there is no technically feasible way to do so. Reasonable changes to preserve or improve sysvinit support should be accepted through the jessie release. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: TC resolution revised draft
On 31/01/14 14:02, Sébastien Villemot wrote: P1: DT UT DL UL P2: DL UL DT UT P3: UT UL DL DT P4: UT UL DL DT Of course, in the alternative scenario with two consecutive ballots (one on the init, followed by one on the coupling), it would not have been possible to express this preference over the relative importance of the two questions, so one could argue that this is a feature of the single ballot with all options. Yes I think this is by design, and IMHO desirable. Imagine if the questions were uncoupled and decided in *reverse* order, someone might decide to compromise on their choice of init system, due to the result of the first decision making their original choice less palatable. I think that's what people are expressing in their vote. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: TC resolution revised draft
On 31/01/14 14:02, Sébastien Villemot wrote: the reason of the victory of upstart in this hypothetical vote is that systemd proponents prefer to lose on the coupling question rather than on the init system question If having systemd is still a preference despite the outcome of the other question, you can avoid losing on it by simply putting the systemd options with equal preference: DT = DL UL UT Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Putting it another way, then, I expect there are some people who will not want systemd on their GNU/Linux systems. I don't think it matters if their reasons are technical, political, irrational fear or personal dislike of the creator; I'd like them to have that choice and for it to work as well as possible. Whatever init system we use on the non-Linux ports (which will certainly not be systemd), I expect it will be fully available to Debian GNU/Linux installs, with init scripts that we'd have to maintain already for the sake of our ports. Hopefully that is some reassurance. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: TC resolution revised draft
On 30/01/14 14:40, Ian Jackson wrote: D DM U UM O OM V VM GR and of course FD I think we can probably leave out one of each of O OM V VM. If anyone has a preference for O and V over OM and VM please say so. Couldn't it bias the outcome if votes might otherwise have been split between O and OM for example? And so better to leave them in? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ea66ef.1060...@pyro.eu.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
On 30/01/14 17:01, Thorsten Glaser wrote: And the GNOME/systemd people are invited to make their dream of the FLOS GNOME OS into a Debian derivate or Pure Blend. If the chosen default is something other than systemd, and if the TC resolution does not prevent GNOME having a hard dependency on systemd interfaces, then systemd would effectively belong to task-gnome-desktop That situation is basically how the pure blends work already? And it still means the Debian GNOME DVD could give the ideal setup for GNOME. And the 'default' can be decided irrespective of what GNOME needs? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ea8bfc.2020...@pyro.eu.org
Bug#727708: call for votes on default Linux init system for jessie
On 19:01, Adrian Bunk wrote: On Tue, Jan 28, 2014 at 07:05:01PM -0500, Michael Gilbert wrote: What makes you think gnome is going to be the default? http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5 Read the text in debian/changelog that is there - the final decision will be made in August (or later). I was sarcastically describing a worst-case scenario that is not completely impossible - in reality I would expect enough sanity in Debian to ensure that something depending on a non-default init system cannot be part of a default installation. I'd expect Debian GNOME install media would still give a GNOME desktop by default, Debian KDE disc gives you KDE, etc. Would it be crazy to suggest putting the preferred init system in the 'task'? A Debian GNOME install would likely install systemd, otherwise it could be something else. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140129172039.gb21...@squeeze.pyro.eu.org
Bug#727708: Init system resolution open questions
On 19/01/14 12:20, Adrian Bunk wrote: Why do you want Debian to support multiple init systems in the first place? I think because: * whichever is chosen as default, there will be some users who specifically don't like it, or specifically want something else (including major consumers like Ubuntu (Upstart), or Spotify (systemd), or Google (SysV)) * the non-Linux ports may have no choice but to get some other init system working anyway (if systemd is chosen as the default on Linux - I am quite certain it would never be ported) * if people are going to be doing the above work anyway, let's make it available to everyone, Linux and non-Linux users alike * if the chosen init system turns out to be a disaster, we'd have an easy way out if we weren't fully reliant on it; or maybe another init system comes along for jessie+1, better than anything we have now, we'd have more agility in being able to adopt it right away (not like this current situation) What level of support (if any) would that guarantee for Debian's ports to non-Linux kernels? I don't think anyone can guarantee that in a volunteer project; nobody can be forced to do the work if they don't want to. Porters may have to work hard and restore any lost functionality they care enough about. I imagine such problems will be RC-severity bugs, so it should be possible within existing practices to get patches applied or NMUd. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52dbda7f.8000...@pyro.eu.org
Bug#727708: Upstart running on GNU/kFreeBSD
James Hunt just let us know they have Upstart running on GNU/kFreeBSD - although not yet doing the /etc/rcS.d early boot tasks like remount root filesystem read-rewrite - it's a fairly significant development: https://lists.ubuntu.com/archives/upstart-devel/2014-January/003010.html AFAIK neither OpenRC nor Upstart have been ported to GNU/Hurd yet, but I'd guess at least one of them could be ported in time for jessie. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: Bits from linux.conf.au
On 15/01/14 21:01, Joerg Jaspert wrote: Likewise I think one can forget the porters of an arch to do so. [...] As much as it may be hated, a clean decision this is it, the rest is officially not supported [...] If the decision were something like that, and only systemd were officially supported, don't expect porters of non-Linux arches to down tools and give up. We may have to drop lots of stuff if we can't get it working without systemd. But I expect we'd still put out a release (official or not) with some other compatible init system and our own init scripts for whatever we have to. I also think some people would care enough about running GNU/Linux without systemd, that we could combine our efforts in that case. I'd like to know as soon as possible if non-Linux ports ought to focus efforts on our existing SysV init, switching to OpenRC, or be trying to port Upstart. I'm personally undecided and the tech-ctte decision could easily sway my opinion on this. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: Bits from linux.conf.au
On 13/01/14 12:15, Thorsten Glaser wrote: Алексей Шилин dixit: In his talk [2] at 13:50 Marc briefly touched the init system choice question. Can you please provide a transcript, for those among us who do not watch any video? In the slides[0] 13 to 15, he summarises init systems something like: * SysV - simple, familiar and deterministic * Upstart - fast boot, makes sense on laptops, but inherently racey * systemd - interesting concept, but too disruptive/complex to buy into Then he gives a preference for Debian's own insserv and startpar. It allows for boot order to be fixed (after running insserv once, the same /etc/rc2.d/Sxx numbering may be rsync'd out to many machines). startpar allows for some limited/controlled amount of concurrency to happen, for extra speed. For servers, their priority is in reliability/reproducibility of boot (especially for pre-deployment testing), as the machines are so rarely rebooted, and engineer time to debug any boot problem is so costly. It's worth mentioning their boot is customised already for their environment. Before the root filesystem is mounted, there seems to be some centralised logging, and an sshd started in the initrd, for human or automated intervention in case the machine doesn't finish booting. That may have pushed them in favour of a simpler init system. [0]: http://marc.merlins.org/linux/talks/ProdNG-LCA2014/ProdNG.odp Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d3e6db.9040...@pyro.eu.org
Bug#727708: Bits from linux.conf.au
On 13/01/14 20:57, Bdale Garbee wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: I'm coming round to the view that we should be planning to support multiple systems indefinitely. This has been my opinion all along. Various assertions that it's somehow just too hard really haven't swayed me. The tricky bit, I think, is to define just what support means in the context of non-default init systems. IIRC, when kfreebsd became a release goal for squeeze, there was some policy that certain fixes were allowed to be handled as RC bugs, especially during the freeze. That allowed porters to potentially get something NMUd or unblocked if it was important to getting things working on that system. Could each proposed/approved init system for jessie be handled like this, generally? The respective teams would contribute the necessary work to make sure things work with that system. Maintainers would need to accommodate reasonable changes (mostly adding native init scripts) if they haven't already. That to me sounds enough like 'supporting' an init system. After committing to such goals, once the work really gets underway, any specific disagreements between teams over how to do things or what's reasonable, could be handled separately as they arise, and escalated to the ctte where necessary? It wouldn't matter to me which is ultimately chosen as the default in that case, if I only knew I wouldn't be wasting my time working on a particular init system. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: init system other points, and conclusion
Commenting as a porter, the decision on default init system might affect me something like this: If GNU/Linux defaults to Upstart, it's likely in porters' interest to get that working as well as possible so we can keep consistency with Linux arches. I'm really grateful of Dimitri's work on this already. But if GNU/Linux defaults to systemd, I'd say that's far too big, too specialised around Linux, and likely to be a moving target to either port it or maintain something compatible. In that case, we may have to do the best we can with one of the other init systems. I'd wonder if it's still worth porting Upstart if few systems would be using it, or packages having Upstart jobs. I have good feelings about OpenRC (which Gentoo already uses as an alternative alongside systemd), or keeping plain sysvinit might even be still viable for jessie only. On Sat, 4 Jan 2014 14:09:57 +0800 Anthony Towns wrote: I wonder if folks could clarify what status they expect secondary init systems to have in Debian? This aspect is most crucial to the ports. At the very least, we'd need to be able to get patches applied to fix startup issues on our init system, even if the maintainer doesn't test or want to support this. In the worst case, we might have to give up on getting something like GNOME working usefully without systemd, and thus not be able to ship it on non-Linux ports. Policy may need to explain whether hard systemd requirement is permissible, if it should be expressed in package dependencies, or what it should do otherwise (e.g. refuse to start, fail with error message, fall back to something with reduced functionality). If policy requires keeping functional sysvinit scripts around for jessie, and/or (more controversially) can discourage the use of specific non-portable functionality - which I think would be things like expect fork or socket activation - I'm not necessarily saying this is a good idea, but it would obviously work in our favour. If non-Linux ports end up running and testing daemons on an alternate init system *anyway*, I'd love for that work to benefit GNU/Linux users who dislike the chosen default init system and want to use what we're using instead. And vice-versa, anyone running such a system and finding/fixing startup issues, would likely be helping the ports. [please keep me in Cc if responding directly to anything I said here] Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Bug#727708: systemd (security) bugs (was: init system question)
As a system administrator, the idea of a 'kitchen sink' init system terrifies me. I would need exceptionally high confidence in its authors and design principles before allowing it to run as root on my systems and depend on it to boot even to single user. I wouldn't even invest much time enquiring into this, if I knew I could manage with something simpler having less scope for security/reliability bugs. OTOH I would be much more forgiving if this were being used for, say, employees' own desktop machines in a protected corporate IT environment. Lots of systemd's features seem particularly convenient for that use case. And security is enforced in other ways there (the only people with access at all, know they risk getting fired for trying to escalate privileges or DoS). Adopting systemd may have been much simpler if it had been separate from and launched by the simple init, starting only the services that have unit files because they really require its functionality. If no installed software on that system needs it, it wouldn't even need to be installed. But otherwise I think there are GNU/Linux users who want the choice of using systemd or being able to use something else. Preferably without having to switch a different distro or third-party derivative. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5298f9d0.8000...@pyro.eu.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
The original question was which init system[s] are going to be the default. But there are still some other things I'm curious about: 1. we already have alternate init systems in the archive; could it be some kind of release goal to ensure they are installable? i.e. make it possible for them to satisfy the dependencies of essential packages. (Steve Langasek's metapackage idea in [0] seems to be in the right direction for accomplishing that, except it wouldn't work for OpenRC or indeed for keeping the original sysvinit/sysv-rc). [0]: http://lists.debian.org/debian-devel/2013/11/msg00389.html 2. would exceptions be permitted; could some packages explicitly depend on a non-default init system if it's the only one providing functionality it needs (and still be part of a stable release)? I'm thinking that GNOME might (someday, if replacements for logind or other APIs can't be found) want to do this, if systemd isn't chosen as the sole default on GNU/Linux. (It seems similar to a maintainer being able to restrict packages to Arch: linux-any if they cannot / do not want to support non-Linux ports). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529907fc.7040...@pyro.eu.org
Bug#727708: init system question before the technical committee
The sysvinit page doesn't have a specific maintainer/advocate. It is a collection of opinions from discussion on debian-devel@ and elsewhere. Other camps have already responded to parts they don't agree with. Unless any volunteers want to make last-minute small changes, it can probably be taken as 'complete' as soon the tech-ctte is ready to move forward with this. I think maintainers of all the other proposals have said they are ready now. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: init system question before the technical committee
Hi, On 10/11/13 18:23, Russ Allbery wrote: What is the current status of the other position statements from the perspective of their maintainers? Do people have a feel for when they'll consider their positions finalized, at least pending Technical Committee feedback and questions? Sorry to be so late with this. I've made some small, final changes to this position statement and I'd like to call it 'complete': https://wiki.debian.org/Debate/initsystem/multiple I don't really feel that any contra $initsystem sections or rebuttals are needed on this page and it reads nicer this way. And I'm too tired to argue this much more; the debate has already taken far more energy than I would like. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi! Please may I suggest another option for consideration: a commitment to support two chosen init systems. On mainstream ports (Linux amd64, i386) where two init systems are available, a package should be tested and made to work reasonably well on both. Any port would have at least one of these init systems. This offers users a choice to avoid a particular init system, try the new features in another one, or perhaps stay with what they already have. It would require work, but maybe this turns argument into something that can be accomplished through team effort. Supposing systemd and sysvinit were chosen: * systemd folks would aim to make best use of the existing sysvinit scripts, and provide help to packages where improvement can be made; * sysvinit users and porters can help ensure things keep working there. I've begun a debate page here, more suggestions are welcome: https://wiki.debian.org/debate/initsystem/multiple or follow up on debian-devel@ Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#699808: tech-ctte: syslinux vs the wheezy release
Hi, On 08/02/13 20:52, Bdale Garbee wrote: Joey Hess jo...@debian.org writes: syslinux is GPL'd, so this would result in shipping d-i images in wheezy which contain a GPL'd binary for which there is no source in wheezy. My unstated assumption was that if d-i were able to successfully build against the syslinux version in sid, that said version would be promoted into testing before the actual release. But the new upload of syslinux would not satisfy the Release Team's freeze policy, would it? As per their most recent 'bits' mail to d-d-a and published at: http://release.debian.org/wheezy/freeze_policy.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51158fbb.5070...@pyro.eu.org
