subject:"Re\: default init on non\-Linux platforms"

On 02/23/2014 12:32 PM, Jonathan Dowland wrote:
 I agree and understand that this was the way to go back in the old
 days, but we shouldn't be using that on current setups.
 
 But you aren't planning on running openrc at all, are you?

No, and I don't see any compelling reason why I should. With systemd
there is one mature solution that does the job well and which is adopted
by most other distributions now.

I was merely expressing that I think that CGroups are an indispensable
if you're planning to use Debian to build modern productive systems with
high availability in mind.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5309dfe0.9000...@physik.fu-berlin.de

Re: default init on non-Linux platforms

2014-02-23 Thread Jonathan Dowland

Please do not CC me, I am subscribed to the list.

On Sun, Feb 23, 2014 at 12:47:44PM +0100, John Paul Adrian Glaubitz
wrote:
 On 02/23/2014 12:32 PM, Jonathan Dowland wrote:
  But you aren't planning on running openrc at all, are you?
 
 No, and I don't see any compelling reason why I should. With systemd
 there is one mature solution that does the job well and which is
 adopted by most other distributions now.

Since you aren't a user nor are going to be a user of openrc, I don't
see why you feel the need to critique it, especially on debian-devel
where the majority of subscribers are just not interested.

 I was merely expressing that I think that CGroups are an indispensable
 if you're planning to use Debian to build modern productive systems
 with high availability in mind.

Yup, but cgroups aren't available on KFreeBSD and one of the main
reasons for openrc in Debian is to provide some init system better than
sysvinit that works on the other kernel we are committed to supporting.
You don't care about KFreeBSD, I don't care about KFreeBSD, but some do
so why not leave them to it and focus your energy on something you do
care about?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140223124314.ga17...@bryant.redmars.org

Re: default init on non-Linux platforms

On 02/23/2014 07:32 PM, Jonathan Dowland wrote:
 
 
 On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz 
 glaub...@physik.fu-berlin.de wrote:

 I agree and understand that this was the way to go back in the old
 days, but we shouldn't be using that on current setups.
 
 But you aren't planning on running openrc at all, are you?

No, he's just planning on more pointless critics.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5309ed56.1060...@debian.org

Re: default init on non-Linux platforms

On 02/23/2014 07:36 PM, Marco d'Itri wrote:
 On Feb 23, Jonathan Dowland j...@debian.org wrote:
 
 But you aren't planning on running openrc at all, are you?
 Who is? Seriously, would you mind stepping forward?
 
 http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrcshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1
 
 What I see here is an handful of people wasting the time of a lot of 
 other people to further their own pet project.

http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rcshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1

sysv-rc wins...

With useless stats, we can say useless things.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5309ee85.4090...@debian.org

Re: default init on non-Linux platforms

On Sun, Feb 23, 2014 at 12:43:14PM +, Jonathan Dowland wrote:
 Since you aren't a user nor are going to be a user of openrc, I don't
 see why you feel the need to critique it, especially on debian-devel
 where the majority of subscribers are just not interested.

Well. OpenRC was up for discussion as the default init, wasn't it?

 You don't care about KFreeBSD, I don't care about KFreeBSD, but some do
 so why not leave them to it and focus your energy on something you do
 care about?

That's correct. However, the problem with kFreeBSD is that I - as a
package maintainer - have to invest extra time to make sure my
packages don't FTBFS on these architectures as otherwise my packages
wouldn't be allowed to migrate to testing. Time which I rather invest
into more important packaging work.

That would be the same as me forcing everyone else to make sure their
packages build fine on m68k even though it has zero relevance.

When Michael Stapelberg asked the audience eduring one of his talks
[1] whether any of them was using the kFreeBSD port, not a single
person was raising their hands, yet everyone else has to deal with it
and yet some people lose their minds when it doesn't get the same
attention as the Linux port.

Adrian

 [1] http://penta.debconf.org/dc13_schedule/speakers/2589.en.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140223130437.gd6...@physik.fu-berlin.de

Re: default init on non-Linux platforms

On Sun, Feb 23, 2014 at 08:50:13PM +0800, Thomas Goirand wrote:
  http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rcshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1
 
 sysv-rc wins...
 
 With useless stats, we can say useless things.

Two things:

- virtually everyone installs systemd in parallel, not by installing
  systemd-sysv as this means you don't have an easy way of going
  back to System V Init in case you shoot yourself into the foot;
  you just install the package and point your init to the systemd
  binary

- System V Init is the current default, of course it's installed
  on virtually all systems

 http://qa.debian.org/popcon-graph.php?packages=systemd+upstart+openrcshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1

Those are the proper stats to be used and you clearly see the trend.

And like your pet project - OpenRC - my pet project - the m68k port -
isn't very popular either:

 http://popcon.debian.org/stat/submission.png

And I am not complaining that we're not making it a stable release,
simply because it's pointless with a documented user base of 9.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140223125734.gc6...@physik.fu-berlin.de

Re: default init on non-Linux platforms

On Sun, Feb 23, 2014 at 08:45:10PM +0800, Thomas Goirand wrote:
 On 02/23/2014 07:32 PM, Jonathan Dowland wrote:
  
  
  On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz 
  glaub...@physik.fu-berlin.de wrote:
 
  I agree and understand that this was the way to go back in the old
  days, but we shouldn't be using that on current setups.
  
  But you aren't planning on running openrc at all, are you?
 
 No, he's just planning on more pointless critics.

Hooray, another init system war on debian-devel on a sunny Sunday!

I know, reliable service starting and process tracking is completely
pointless and setting architectures with a neglectable userbase is
what we should all invest our efforts into.

I'm out, the weather is too nice :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140223130643.ge6...@physik.fu-berlin.de

Re: default init on non-Linux platforms

previously on this list Matthias Urlichs contributed:

  Kevin, I don't think you understand the reasoning behind this. Again,
  the problem the init system has to solve here is being able to track a
  process with a 100% accuracy, so whatever automated mechanisms you have
  configured when certain situations occur, they have to find the correct
  process to work on as to not kill the daemon instance you actually
  still need.

 … not to mention any other processes which the daemon started, which
 may or may not linger after its (grand)parent died, and which may or
 may not cause problems when restarting.

Never happened to me and shouldn't happen on a well designed service
that should be controlling it's children. If it does happen you should
be checking the system over anyway and possibly filing a bug.

The only time I've had zombies is on a desktop.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/706169.64541...@smtp137.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

On Fri, 21 Feb 2014 23:53:51 +0100
John Paul Adrian Glaubitz wrote:

 Kevin, I don't think you understand the reasoning behind this. Again,
 the problem the init system has to solve here is being able to track a
 process with a 100% accuracy, so whatever automated mechanisms you have
 configured when certain situations occur, they have to find the correct
 process to work on as to not kill the daemon instance you actually
 still need.
 

ADRIAN, I hate it when people use your name thinking it makes any
difference to the content your about to spout.

 And, to my current knowledge, this is not possible without a mechanism
 like CGroups. Whether you rely on PID files or grep through the output
 of ps or use pidof, either of them are fragile and prone to fail.
 

Regex works just fine for me.

 I elaborated in my actual real-life case how PID files are prone to
 failure - I am aware that the situation with the full filesystem
 shouldn't occur in the first place,

Right including the rest of this email that's two counts of fantasy or
bad practice now justifying increased complexity in the kernel.

  but, well administrators are just
 humans after all - and, using ps to track the process you are looking
 for to be able to restart, stop or kill it, can obviously be easily
 tricked into failure as well. 

 I was merely expressing that I think that CGroups are an indispensable
 if you're planning to use Debian to build modern productive systems with
 high availability in mind.

As I have already said in previous threads that you have obviously
forgotten from months ago. Something like CARP for complete server
redundancy or Ciscos redundancy protocol, I forget what it is called
is the way to go for many reasons.

 Just imagine some other (malicious)
 process using the same name as well or when you need to control
 different instances of the very same process.

So you keep machines that are running malicious processes online by
adding complexity to the kernel. It is people like you that meant that
kernel.org was offline for months after rediculously simple measures
weren't bothered with.

If you are lucky enough to have malicious processes that can be found
rather than a rootkit then you should be pulling the plug investigating
and hardening before all your machines take part in a DDOS.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/648730.64541...@smtp137.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

previously on this list Marco d'Itri contributed:

  But you aren't planning on running openrc at all, are you?  
 Who is? Seriously, would you mind stepping forward?

If it was available I would use it but wouldn't be switching cgroups
on or would be switching them off even if I hadn't bothered to
compile them out of the kernel out of principle and to catch any
nonsense that *required* them because some daemon writer has now decided
they don't need to bother with tracking their own children anymore.

When I used OpenRC on Alpine Linux I found it far nicer to work with
than any of systemd, upstart or syv-rc. The only one I find nicer to
work with is OpenBSD's.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/277875.64541...@smtp137.mail.ir2.yahoo.com

Re: default init on non-Linux platforms


Perhaps before this thread spirals out of control I should re-iterate
that what I said was cgroups doesn't pass the worth-it barrier for me
and not that they have NO value.

I also mentioned pgroups for those that do want this functionality but
also want portability and not bugs in daemons on one system but not
another increasing forking, reducing eyefall, collaboration etc. and
perhaps want a simpler solution.

The benefit that Linux and even firefox etc. has gained from OpenBSD's
practically paranoid bug fixing as well as finding the bugs for all the
platforms it's userland still runs on especially in compiler tools
should be realised and not underestimated. To some degree it will be
true for debians HURD and is it kfreebsd too. So I don't get the
holding Linux back rubbish especially when it is often based on
superficial arguments that carry little weight, atleast in my eyes.
Isolating Linux would hold it back and make it a flakier system in my
eyes.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/924308.73795...@smtp129.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

On 02/23/2014 08:57 PM, John Paul Adrian Glaubitz wrote:
On Sun, Feb 23, 2014 at 08:50:13PM +0800, Thomas Goirand wrote:

http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rcshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1

sysv-rc wins...

With useless stats, we can say useless things.

Two things:

- virtually everyone installs systemd in parallel, not by installing
systemd-sysv as this means you don't have an easy way of going
back to System V Init in case you shoot yourself into the foot;
you just install the package and point your init to the systemd
binary

- System V Init is the current default, of course it's installed
on virtually all systems

http://qa.debian.org/popcon-graph.php?packages=systemd+upstart+openrcshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1

Those are the proper stats to be used and you clearly see the trend.

And like your pet project - OpenRC - my pet project - the m68k port -
isn't very popular either:

http://popcon.debian.org/stat/submission.png

And I am not complaining that we're not making it a stable release,
simply because it's pointless with a documented user base of 9.

Adrian

Marco and yourself are *a way* off topic. Please at least have the
decency to rename the subject of the tread to systemd fanboys flamewar
yet-again bashing OpenRC just for fun or something similar (but
preferably: don't just do that in this list, and avoid replying about
anything related to OpenRC, since we all know what type of
non-productive content it's going to be).

On 02/23/2014 09:04 PM, John Paul Adrian Glaubitz wrote:
Well. OpenRC was up for discussion as the default init, wasn't it?

Yes, *was*. Now, move on, we're not discussing this anymore. If you
didn't notice the subject of this thread, it is:
default init on non-Linux platforms

On 02/23/2014 09:06 PM, John Paul Adrian Glaubitz wrote:
I'm out, the weather is too nice :).

Exactly: you have better things to do. So please stay out (of this
thread and anything else related to OpenRC) and never come back.

Thomas

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530a0f23.3070...@debian.org

Re: default init on non-Linux platforms

On 02/21/2014 03:37 AM, Ondřej Surý wrote:
 mkdir -p /run/openrc
 touch /run/openrc/softlevel
 
 and then it still doesn't work as expected:
 
 root@howl:/etc/init.d# /etc/init.d/rsyslog start
  * WARNING: rsyslog is already starting
 
 root@howl:/etc/init.d# /etc/init.d/rsyslog stop
  * ERROR: rsyslog stopped by something else
 
 root@howl:/etc/init.d# /etc/init.d/rsyslog status
  * status: stopped
 
 root@howl:/etc/init.d# ps uax | grep rsyslo[g]
 root  6743  0.0  0.0  52592  1752 ?Ssl  20:28   0:00
 /usr/sbin/rsyslogd -n -c5
 root  6764  0.0  0.0   7768   856 pts/0S+   20:28   0:00 grep
 rsyslog
 
 Thomas, would it be possible to make openrc-run work even when the
 openrc doesn't replace /etc/init.d/rc{,S}? Or does it need too much from
 openrc infrastructure, so my idea is just too crazy?

I'm not sure about how much work it would be, or how easy it would be to
implement, but the more I think about it, the more I think it'd be great
to do this.

The only problem I'd see, is that we'd have to keep the LSB headers,
since startpar / insserv would still only understand that. Though that's
probably the least annoying part. If at least we can rewrite the rest of
the scripts using the runscripts simplification, and have this available
by default in Jessie, then it'd be awesome. Switching between OpenRC and
sysv-rc can be dealt with later then (since what's important is to have
runscript support as early as possible).

I'll see with the rest of the contributors what they think about it, but
Benda seem to be positive about the fact it's doable. I'd also like to
patch sysv-rc so that it could write in /run/openrc/started, so that we
get a list of running daemon when switching to OpenRC (and avoid the
hack of parsing with for file in /etc/rc0.d to do a manual shutdown
after the switch).

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530a110c.8070...@debian.org

Re: default init on non-Linux platforms

2014-02-23 Thread Matthias Urlichs

Hi,

Kevin Chadwick:
 Regex works just fine for me.
 
One sample usecase where they dont't: the system is wedged / overcommitted
and I need to terminate some services; guess I'll start another ten processes
to do that. Yeah, right.

I'll be nice to everybody else here and not enumerate any others.

 … not to mention any other processes which the daemon started, which
 may or may not linger after its (grand)parent died, and which may or
 may not cause problems when restarting.

 Never happened to me and shouldn't happen on a well designed service
 that should be controlling it's children. If it does happen you should
 be checking the system over anyway and possibly filing a bug.

*its children.

Besides, this is immaterial; a well-designed init should be able to cope
with not-well-designed services and furthermore should be able to help
me debug them if/when that happens. 


To summarize:

Please stop bashing features just because you happen to not
need ^w want them.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

previously on this list Kevin Chadwick contributed:

 Perhaps before this thread spirals out of control I should

should also mention this has been discussed on this very list already,
though before I was enrolled and the following response went
unreplied to. 

On the other hand and I doubt of significance to me but it may well be
worth looking into how Google uses cgroups though apparently systemd
causes or would cause problems for them in potential kernel changes
being incompatible with their usage. May have been resolved and brought
up before though I forget if replied to, but might provide some
pro argument for the cgroups case for the few that it matters to
rather than the many that enforcing it's usage matters to.

https://lists.debian.org/debian-devel/2011/07/msg00423.html

___

 It seems this problem (double fork) is the basement of using cgroup
 under systemd ;)

 I think messing around with cgroups is a ridiculous way to solve this
 problem.

To be fair, systemd also uses cgroups to reliably kill rogue child
processes when stopping a service.  This is not unlike what BSD-derived
shells use pgroups for, I believe.

 The right answer is simply to change the daemons to give
 them an option which causes them not to fork.  Then you can just have
 a single supervision daemon which reaps (and restarts, if desired).

 I haven't done a survey of the available init replacements but this is
 not a new concept

Well, it's already present in SV init :

  1:2345:respawn:/sbin/getty 38400 tty1

 and I hope that most of them implement it as a possibility.

Daemontools, runit, minit, upstart, systemd all do.  I don't know about
initng.

-- Juliusz



-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/489578.4170...@smtp104.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

previously on this list Matthias Urlichs contributed:

 One sample usecase where they dont't: the system is wedged / overcommitted
 and I need to terminate some services; guess I'll start another ten processes
 to do that. Yeah, right.
 
 I'll be nice to everybody else here and not enumerate any others.

Again that means your system is badly designed or administered without
proper restraints such as nice and limits which are important for
other reasons. Pkill root owned processes are hardly demanding but quite
the opposite.

not-well designed services should be fixed.

Why should I HAVE to have any evil when I don't have ANY need for it
and have much more important things depending on the kernel to be secure.

unfortunately cgroups are a necessary evil - Linus Torvalds

Should have added for a select few and others that don't know what
they are doing!

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/400062.71270...@smtp120.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

2014-02-23 Thread Marco d'Itri

On Feb 23, Thomas Goirand z...@debian.org wrote:

 Marco and yourself are *a way* off topic. Please at least have the
 decency to rename the subject of the tread to systemd fanboys flamewar
 yet-again bashing OpenRC just for fun or something similar (but
 preferably: don't just do that in this list, and avoid replying about
 anything related to OpenRC, since we all know what type of
 non-productive content it's going to be).
This is not about systemd or any other init system.
This is about how much additional work the five OpenRC users will cause 
to other developers.

Also, if I were bashing it just for fun then I would not forget 
mentioning its Gentoo origin.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

2014-02-23 Thread The Wanderer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/23/2014 03:29 PM, Marco d'Itri wrote:

 On Feb 23, Thomas Goirand z...@debian.org wrote:
 
 Marco and yourself are *a way* off topic. Please at least have the
 decency to rename the subject of the tread to systemd fanboys
 flamewar yet-again bashing OpenRC just for fun or something
 similar (but preferably: don't just do that in this list, and avoid
 replying about anything related to OpenRC, since we all know what
 type of non-productive content it's going to be).
 
 This is not about systemd or any other init system.
 
 This is about how much additional work the five OpenRC users will
 cause to other developers.

To be fair, you would also have to add all the Hurd and kFreeBSD users -
and even if you assume that everyone who runs popcon on an amd64
kFreeBSD box also runs it on an i386 kFreeBSD box, and also runs it on a
Hurd box just for 100% overlap, according to the popcon front page
that's still 82 current users.

That's less than one in 2000 popcon submissions, which is not even a
drop in the total bucket - but it's much more than 5, and is still only
counting people who run popcon. (Which I often don't, because it breaks
my reflexive attempts to tab-complete 'popd' when I'm root.)

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTCl/4AAoJEASpNY00KDJry+EQAIKNnlm7r76b65+FI5gpWdwr
u5vnLlGWLx44K4PeIplZSmmEml0HXY41M2P7FL09bOtluXRJDv2xvJuogN8MXb6B
ff5i+kjbFbBT6SfYdIsCzS2bShP96UUG+bTALWuqwTOiUZp2w37GjiFBSzWcmcGl
j56imuiCMqIdoVrQFvYrB3gUKuDhsfbcvOU17suevdosu/fybzvjIvxQBSya+0iI
pTKWagygNyAEixpHnpGlaYyYTgHr4AIgGgjABULFsPzmVBFqomv8yr1VoHzf5hE4
3EbW5Bb/tzX2gjJraQkZXScsAfQ945T6baD6Ez5PN9RdLXwS4x5hfVN80JF0MlQq
IM/LxlXS8bjSyPWadVoK8ev+P8IJKoZwoew4QtGTwaK95/qd2jK0q/0jfA4tJcRQ
HECSCUpDyt28FiUF+BTfb+nsVsy0vGXDBghVIH6as23G2f75gONXlpLtbHv0kf9E
FEf++Pn1j8CBupehDlZnFTb4w9Fq1n6N8D0MBObyxDzVyA5ihPf/Mo0MKUDx0NDE
DqDmyxCM1cFsCO/Pq3KP9FLzfyv/bAR/H4T/rhMk1y1G9JxqTyhs3wVzzsBYSLKC
WxhNl+kICrp5qx+tk170fRIfXkFrxanuFk15h3nWSPZCv+0hsdwWGMk08RKTTPBr
X6nYHVaj6G2WKUeNmArW
=PHl0
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530a5ff8.8060...@fastmail.fm

Balance of portability and maintenance burden (Re: default init on non-Linux platforms)

2014-02-23 Thread heroxbd

Hey Adrian,

John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes:

 That's correct. However, the problem with kFreeBSD is that I - as a
 package maintainer - have to invest extra time to make sure my
 packages don't FTBFS on these architectures as otherwise my packages
 wouldn't be allowed to migrate to testing. Time which I rather invest
 into more important packaging work.

If you are that concerned about the maintenance burden, I am happy to
say OpenRC packagers are willing to help in this situation for any
OpenRC related issues. Just bug us.

On kFreeBSD, IMHO, diversity is quite a good thing, even from a packager
maintainer PoV. Making your package portable in the correct way (say,
not temperary conditional block hacks) is generally good for its
rubostness. Implicit assumptions to a single environment ease our tasks
in the short run, but accumulate and exploit the health of the package
in the long run.

Cheers,
Benda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/86a9dhs71i.fsf...@moguhome00.in.awa.tohoku.ac.jp

Re: default init on non-Linux platforms

2014-02-23 Thread heroxbd

Dear Kevin,

Kevin Chadwick ma1l1i...@yahoo.co.uk writes:

 The benefit that Linux and even firefox etc. has gained from OpenBSD's
 practically paranoid bug fixing as well as finding the bugs for all the
 platforms it's userland still runs on especially in compiler tools
 should be realised and not underestimated. To some degree it will be
 true for debians HURD and is it kfreebsd too. So I don't get the
 holding Linux back rubbish especially when it is often based on
 superficial arguments that carry little weight, atleast in my eyes.
 Isolating Linux would hold it back and make it a flakier system in my
 eyes.

Thanks! That's exactly what I want to say.

I would like to have Debian GNU/kFreeBSD and GNU/Linux, butterflies and
human beings share this planet.

Benda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/861tyts6di@moguhome00.in.awa.tohoku.ac.jp

Re: default init on non-Linux platforms

On 02/24/2014 04:29 AM, Marco d'Itri wrote:
 On Feb 23, Thomas Goirand z...@debian.org wrote:
 
 Marco and yourself are *a way* off topic. Please at least have the
 decency to rename the subject of the tread to systemd fanboys flamewar
 yet-again bashing OpenRC just for fun or something similar (but
 preferably: don't just do that in this list, and avoid replying about
 anything related to OpenRC, since we all know what type of
 non-productive content it's going to be).
 This is not about systemd or any other init system.
 This is about how much additional work the five OpenRC users will cause 
 to other developers.

Probably you missed the point. Maybe because you don't really know what
OpenRC is about and what it does. Let's say we don't bring in new
packages, then it's 100% supported *right now* in Debian, using the
already existing LSB header init scripts. If there's new packages, then
it's probably more easy to use the simplified runscripts rather than the
traditional sysv-rc LSB header init.d scripts.

Also, it is my understanding that we wouldn't force anyone to add
support unless a patch is provided. I have no problem with that rule.

What additional work are you therefore talking about? It'd be actually
less work. The goal here is to *simplify* the maintenance of init
scripts (as well, for non-linux ports), by making it possible to use the
OpenRC syntax instead of the one of LSB header scripts which everyone
wants to get rid of.

OpenRC addresses the needs of about the 160k current users of sysv-rc.
This has nothing to do with the 800 systemd users (note: if you didn't
get it, I well know this is silly stats, I'm just using the same kind of
argumentation to show how pointless it is to use these stats in such a way).

Now that systemd is to become the default init system, at least let us
discuss peacefully about ways to address the problem of its
non-availability on some ports, and how to deal without systemd (also on
linux ports), for those who don't want to use it. If you aren't
interested in this topic, just don't read. Nobody forces you to do so.
The topic well identifies the content of the thread.

 Also, if I were bashing it just for fun then I would not forget 
 mentioning its Gentoo origin.

Very constructive. Thanks.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530af289.8090...@debian.org

Re: default init on non-Linux platforms

2014-02-22 Thread Matthias Urlichs

Hi,

John Paul Adrian Glaubitz:
 Kevin, I don't think you understand the reasoning behind this. Again,
 the problem the init system has to solve here is being able to track a
 process with a 100% accuracy, so whatever automated mechanisms you have
 configured when certain situations occur, they have to find the correct
 process to work on as to not kill the daemon instance you actually
 still need.
 
… not to mention any other processes which the daemon started, which
may or may not linger after its (grand)parent died, and which may or
may not cause problems when restarting.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

2014-02-21 Thread Simon McVittie

On 20/02/14 19:37, Ondřej Surý wrote:
 I have split openrc into openrc and openrc-sysv moving the conflicting
 parts to openrc-sysv on my system, and it install just fine

If sysv-rc's invoke-rc.d and update-rc.d should be treated as generic
glue shared by multiple inits (which they probably should, since they
already support all of sysv-rc/insserv, Upstart, systemd) then it might
make more sense to move them to sysvinit-utils, and include openrc
support in them there.

According to `apt-file search invoke-rc.d`, the only implementations of
invoke-rc.d or update-rc.d in Debian are sysv-rc, file-rc and openrc
(plus an update-rc.d in multistrap which I assume is some sort of
wrapper); systemd and Upstart both rely on the one from sysvinit.

file-rc appears to be basically dead, and hasn't been updated for
dependency-based boot. Upstart already has a hard dependency on sysv-rc.
Perhaps systemd (or at least systemd-sysv) should have that as well, or
Breaks: file-rc, or something, since I doubt file-rc's update-rc.d deals
with systemd units; systemd currently depends on initscripts, which
depends on sysv-rc|file-rc. I'll open a bug.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530722b0.9000...@debian.org

Re: default init on non-Linux platforms

2014-02-21 Thread John Paul Adrian Glaubitz

On 02/21/2014 04:20 AM, hero...@gentoo.org wrote:
 OpenRC needs a proper directory structure in /run/openrc to track the
 status of services. It is handled by init.sh and friends, you may need
 to hack that.

So, OpenRC actually also relies on files - like System V Init - to
track the state of a service? Isn't that approach somewhat unreliable
and hacky?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53072a4c.7090...@physik.fu-berlin.de

Re: default init on non-Linux platforms

2014-02-21 Thread heroxbd

Dear Adrian,

John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes:

 So, OpenRC actually also relies on files - like System V Init - to
 track the state of a service? Isn't that approach somewhat unreliable
 and hacky?

I bet you are going to tell me the only reliable and non-hacky way to
track the state of a service is not forking/writing to files but
starting it foreground by a long-living daemon. I agree with you.

OpenRC leverages cgroups when available. We are also working on a plugin
framework for external supervisors such as djbtools, runit and s6 (maybe
launchd, smf, systemd, ... as well if they're hackable) to do this
foreground status tracking while integrated with OpenRC: We are not
there yet though.

These advanced features are optional. We can still use the unreliable
and hacky way of trakcing files when the task is trivial, like a
personal VPS or laptop which do not care much about running sshd/httpd
for 3 years non-stop.

Thanks for the insight.
Benda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86eh2w8ylo@moguhome00.in.awa.tohoku.ac.jp

Re: default init on non-Linux platforms

2014-02-21 Thread John Paul Adrian Glaubitz

On 02/21/2014 01:00 PM, hero...@gentoo.org wrote:
 So, OpenRC actually also relies on files - like System V Init - to
 track the state of a service? Isn't that approach somewhat unreliable
 and hacky?
 
 I bet you are going to tell me the only reliable and non-hacky way to
 track the state of a service is not forking/writing to files but
 starting it foreground by a long-living daemon. I agree with you.

Well, I was thinking about something like CGroups. I don't like the
idea of having to rely on files for an init system to be able to
track the processes it has started.

I agree and understand that this was the way to go back in the old
days, but we shouldn't be using that on current setups.

At my department, we stumbled right over this design when the /var
filesystem was full and System V Init could no longer create PID
files to be able to track services, yet it started services without
complaining.

Since we had to restart our dhcpd several days on a particular day,
System V Init was unable to track whether the daemon was already
running and we ended up with several dozen instances.

Sure, it's probably a bug in the init script used as it didn't
check for enough disk space and wasn't failing when the disk is full.
But again, this is a core component depending on external scripts
being bug free which is not the correct approach when you are
aiming for something robust.

 OpenRC leverages cgroups when available. We are also working on a plugin
 framework for external supervisors such as djbtools, runit and s6 (maybe
 launchd, smf, systemd, ... as well if they're hackable) to do this
 foreground status tracking while integrated with OpenRC: We are not
 there yet though.

Can external supervisors like djbtools or runit actually reliably track
processes and if, yes, how? From my understanding, it's impossible
to be able to really track a process once it has started when
you don't have the possibility to use something like CGroups as
services could always just double-fork. The tracking has to be
done through a mechanism provided by the kernel, doesn't it?

And grepping through the output of ps or similar is not what
I would consider reliable and robust either.

 These advanced features are optional. We can still use the unreliable
 and hacky way of trakcing files when the task is trivial, like a
 personal VPS or laptop which do not care much about running sshd/httpd
 for 3 years non-stop.

Sure, I fully agree. But there are actually many enterprises who
need something with 99% service availability. Our department
runs a webserver, a login node for 1200 users and a large compute
clusters with over 200 nodes and an SGI UV1000 (1024 CPUs, 2 TiB),
so we need something which is able to control resources and track
processes. Many enterprises and websites run Debian.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5307451b.1010...@physik.fu-berlin.de

Re: default init on non-Linux platforms

2014-02-21 Thread heroxbd

Dear Adrian,

John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes:

 On 02/21/2014 01:00 PM, hero...@gentoo.org wrote:
 So, OpenRC actually also relies on files - like System V Init - to
 track the state of a service? Isn't that approach somewhat unreliable
 and hacky?
 
 I bet you are going to tell me the only reliable and non-hacky way to
 track the state of a service is not forking/writing to files but
 starting it foreground by a long-living daemon. I agree with you.

 Well, I was thinking about something like CGroups. I don't like the
 idea of having to rely on files for an init system to be able to
 track the processes it has started.

 I agree and understand that this was the way to go back in the old
 days, but we shouldn't be using that on current setups.

 At my department, we stumbled right over this design when the /var
 filesystem was full and System V Init could no longer create PID
 files to be able to track services, yet it started services without
 complaining.

 Since we had to restart our dhcpd several days on a particular day,
 System V Init was unable to track whether the daemon was already
 running and we ended up with several dozen instances.

 Sure, it's probably a bug in the init script used as it didn't
 check for enough disk space and wasn't failing when the disk is full.
 But again, this is a core component depending on external scripts
 being bug free which is not the correct approach when you are
 aiming for something robust.

Thank your for sharing with us your real life story. I can reasonate
with it: having a dhcpd malfunctioning and hundreds of people
complaining about the resulting unstable network is no fun at all.

How to cope with this will be a matter of personal taste. You might
think a robust framework will make it fool-proof. While I might think
running a central dhcp server along with something else which possibly
fill up the /var is questionable itself. I appreciate both.

 OpenRC leverages cgroups when available. We are also working on a plugin
 framework for external supervisors such as djbtools, runit and s6 (maybe
 launchd, smf, systemd, ... as well if they're hackable) to do this
 foreground status tracking while integrated with OpenRC: We are not
 there yet though.

 Can external supervisors like djbtools or runit actually reliably track
 processes and if, yes, how? From my understanding, it's impossible
 to be able to really track a process once it has started when
 you don't have the possibility to use something like CGroups as
 services could always just double-fork. The tracking has to be
 done through a mechanism provided by the kernel, doesn't it?

I've meant foreground, the opposite of double-fork, which has been
discussed in the list, like:

http://article.gmane.org/gmane.linux.debian.devel.general/152538

This does not require a special tracking mechanism in the kernel.

Double-fork is not a reliable way to track process. People invented it
as a hack back in history (from BSD community if I remember it right).

 And grepping through the output of ps or similar is not what
 I would consider reliable and robust either.

Nod. grepping `ps` is what we should avoid at all cost.

 These advanced features are optional. We can still use the unreliable
 and hacky way of trakcing files when the task is trivial, like a
 personal VPS or laptop which do not care much about running sshd/httpd
 for 3 years non-stop.

 Sure, I fully agree. But there are actually many enterprises who
 need something with 99% service availability. Our department
 runs a webserver, a login node for 1200 users and a large compute
 clusters with over 200 nodes and an SGI UV1000 (1024 CPUs, 2 TiB),
 so we need something which is able to control resources and track
 processes. Many enterprises and websites run Debian.

Yes, though I am a casual user, I actually had systemd and monit to
supervise httpd in one of our mirror servers. And I myself am even using
a computing cluter running RHEL5 (for stability and paid customer
service). So I am quite sharing the view with you. Different people in
different situations have different needs: Using a bad old pid-file
tracking, or no tracking at all is like wearing jeans at home, or even
naked. It happily coexists with the situation of wearing suites doing
public speech.

--- super light-hearded, just for fun, don't take it seriously ---
modern activists: com'on, just us, or you'll not be supported.
(com'on, wear suites, or you're out)
old nerds: fine, we will support ourselves.
(fine, we will find somewhere comfortable to be naked)
--- end ---

Hope this explains why I am devoting to something alternative and even
counter-advertised as suboptimal. Let's coexist and have fun. This
universe is ultimately a friendly place to live in after all.


Coming back to our starting point: service relying on file-tracking is
hackish and is recommended to be avoided in serious business in
preferrence to a better available supervising solution.

Re: default init on non-Linux platforms

2014-02-21 Thread Kevin Chadwick

previously on this list hero...@gentoo.org contributed:

  And grepping through the output of ps or similar is not what
  I would consider reliable and robust either.  
 
 Nod. grepping `ps` is what we should avoid at all cost.

All cost? While I like OpenRC and thanks to Gentoo for it and like
your mention of each to there own (I am no old-nerd by the way). I have
to disagree.

If a service fails I am more interested in why and what will happen if
it restarts and not is it back-up already. For that, I would use
redundant servers which in any way you look at it and especially for
high availability situations must be more reliable than trying to
restart a failed service blindly that may not operate as it should when
it does.

Functional externally generated tests like https returned this file are
most valuable for monitoring services and I don't really see your point
or the major benefit at all, especially if it involves increased kernel
complexity.

cgroups doesn't break that, worth it, question for me personally.

However whilst I have found the reasoning by the CTTE to have been
rather disappointing and superficial and I am unlikely to ever use
systemd due to having fundamental issues with it. If a major concern was
portability and many of you have your heart set on systemd then
although it goes against my desires and technical concerns then perhaps
pgroups are worth a mention.




http://marc.info/?l=openbsd-miscm=135313692911156w=2


how can someone write this and not explain why a process managing
pgroups can't achieve the same results?

pgroups is going to be the first alternative for someone instinctively
looking for a portable alternative, so i'm genuinely interested in
knowing why they've discarded the idea

i am, however, aware of differences *unrelated* to writing a systemd
like appliance. pgroups do not provide per item hostname and other
virtualization facilities in freebsd jails/linux cgroups, but what
about *relevant* differences? something weak like the index for for
cgroups is wide enough to fit an UUID? in other words, something that
*doesn't* require a completely new api?




http://marc.info/?l=openbsd-miscm=135314269712851w=2

therefore the requirement for cgroups is completely arbitrary

also of interest:

* early versions of systemd documentation advised daemon authors not
to double fork. presumably cgroups wasn't in the radar at the time

* several (all?) openbsd daemons have options for not double-forking.
some of these daemons have the gall of preceding systemd




-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/163088.43505...@smtp102.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

2014-02-21 Thread John Paul Adrian Glaubitz

On 02/21/2014 11:38 PM, Kevin Chadwick wrote:
 previously on this list hero...@gentoo.org contributed:
 
 And grepping through the output of ps or similar is not what
 I would consider reliable and robust either.  

 Nod. grepping `ps` is what we should avoid at all cost.
 
 All cost? While I like OpenRC and thanks to Gentoo for it and like
 your mention of each to there own (I am no old-nerd by the way). I have
 to disagree.

Kevin, I don't think you understand the reasoning behind this. Again,
the problem the init system has to solve here is being able to track a
process with a 100% accuracy, so whatever automated mechanisms you have
configured when certain situations occur, they have to find the correct
process to work on as to not kill the daemon instance you actually
still need.

And, to my current knowledge, this is not possible without a mechanism
like CGroups. Whether you rely on PID files or grep through the output
of ps or use pidof, either of them are fragile and prone to fail.

I elaborated in my actual real-life case how PID files are prone to
failure - I am aware that the situation with the full filesystem
shouldn't occur in the first place, but, well administrators are just
humans after all - and, using ps to track the process you are looking
for to be able to restart, stop or kill it, can obviously be easily
tricked into failure as well. Just imagine some other (malicious)
process using the same name as well or when you need to control
different instances of the very same process. pidof might help
when you have the full path. But how does that keep you from working
on the wrong instance?

I have been looking for a solution of solving that problem without
CGroups, but I haven't really found one yet.

Do you know one?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5307d8ff.1000...@physik.fu-berlin.de

Re: default init on non-Linux platforms

2014-02-20 Thread gregor herrmann

On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:

 That package does currently depend on
 perl, though, which isn't appropriate for an essential package.
 ...  The dependency is because
 deb-systemd-helper uses a bunch of modules that are not currently in
 perl-core (File::Path, File::Basename, File::Find, File::Temp,
 Text::ParseWords, and Data::Dumper,

I might be missing something but they all seem to be in perl core:

% for m in File::Path File::Basename File::Find File::Temp Text::ParseWords 
Data::Dumper ; do corelist $m ; done

Data for 2014-01-09
File::Path was first released with perl 5.001

Data for 2014-01-09
File::Basename was first released with perl 5

Data for 2014-01-09
File::Find was first released with perl 5

Data for 2014-01-09
File::Temp was first released with perl v5.6.1

Data for 2014-01-09
Text::ParseWords was first released with perl 5

Data for 2014-01-09
Data::Dumper was first released with perl 5.005


Cheers,
gregor


-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #59:  failed trials, system needs redesigned 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140220085738.gj5...@colleen.colgarra.priv.at

Re: default init on non-Linux platforms

2014-02-20 Thread Ansgar Burchardt

Hi,

On 02/20/2014 09:57, gregor herrmann wrote:
 On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
 That package does currently depend on
 perl, though, which isn't appropriate for an essential package.
 ...  The dependency is because
 deb-systemd-helper uses a bunch of modules that are not currently in
 perl-core (File::Path, File::Basename, File::Find, File::Temp,
 Text::ParseWords, and Data::Dumper,
 
 I might be missing something but they all seem to be in perl core:

I think Russ means they are not part of perl-base package, but provided
by perl/perl-modules in Debian. So packages using them have to depend on
the full perl package instead of the minimal perl-base package.

However this could be fixed by moving the additional modules to
perl-base (increasing its size slightly) or changing the implementation
to not use them.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5305d04c.4080...@debian.org

Re: default init on non-Linux platforms

2014-02-20 Thread gregor herrmann

On Thu, 20 Feb 2014 10:52:12 +0100, Ansgar Burchardt wrote:

 On 02/20/2014 09:57, gregor herrmann wrote:
  On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
  ...  The dependency is because
  deb-systemd-helper uses a bunch of modules that are not currently in
  perl-core (File::Path, File::Basename, File::Find, File::Temp,
  Text::ParseWords, and Data::Dumper,
  I might be missing something but they all seem to be in perl core:
 I think Russ means they are not part of perl-base package, but provided
 by perl/perl-modules in Debian. So packages using them have to depend on
 the full perl package instead of the minimal perl-base package.

Ehm, yeah, right.

I already had the feeling that it was too early when I started to
write this mail. - Sorry.
 
Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #9:  doppler effect 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140220102948.gk5...@colleen.colgarra.priv.at

Re: default init on non-Linux platforms

2014-02-20 Thread Thomas Goirand

On 02/20/2014 02:10 AM, Kevin Chadwick wrote:
 Do people use all those runlevels?

As much as I know, there's only 4 in use (using names of OpenRC here,
since OpenRC has named runlevels):
- shutdown (runlevel 0)
- recovery (runlevel 1)
- reboot (runlevel 6)
- default (often, everything else, but most of the time, it's runlevel 2
or 4)

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5305efed.4020...@debian.org

Re: default init on non-Linux platforms

2014-02-20 Thread Thomas Goirand

On 02/20/2014 09:02 PM, Tom H wrote:
 What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
 doesn't have?

Just to name a few:
- getting rid of the ugly LSB headers
- cgroup supports to kill processes
- rc_hotplug (a hotplugged service is one started by a dynamic dev
manager when a matching hardware device is found).
- Checks if a daemon is really started by start-stop-daemon
- Dependency loop breaking system
- Named runlevels (I already talked about that)
- Stateful system (see rc-status)
- Dependency caching system (so you wont have to wait for its
calculation at next boot)
- ... (that's from top of my head, I may have forget some...)

And of course:
- minimalistic declarative runscripts, instead of huge init.d scripts.
A quick example that I wrote myself is available here:
http://thomas.goirand.fr/blog/?p=147

You may find more examples inside the source code of openrc (in the
Debian source package for example), under init.d.misc. Interestingly, in
it you may see that simple things are very simple, but it's also
possible to make complex runscripts when needed (yes, the hard reality,
sometimes means that complex things are needed at boot time).

What's coming:
- monit integration in runscripts (so you can have monit to restart
crashed services, and send emails when they do). We already have patches
available for it, so it's taking a good shape.
- s6 (or equivalent) process monitoring. This is still under discussion
upstream.

There's some goodies which are more Gentoo oriented, like their network
integration, but I don't think it's worth mentioning as I don't think
these features would be useful for Debian, unless someone works on
adapting them (for example, to read /etc/network/interfaces instead of
whatever Gentoo uses).

Also, we have an ALIVE UPSTREAM TEAM, and an evolving project, which is
IMO important (is there anyone still working on sysv-rc apart from a few
Debian maintainers? my understanding is: we're alone now...).

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53061128.1080...@debian.org

Re: default init on non-Linux platforms

2014-02-20 Thread Didier 'OdyX' Raboud

Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit :
 On 02/20/2014 09:02 PM, Tom H wrote:
  What features does sysvinit+openrc have that
  sysvinit+sysv-rc+insserv doesn't have?
 
 Just to name a few:
 - getting rid of the ugly LSB headers

They might be ugly, but they encode the dependency tree; by what are 
they replaced in OpenRC?

 - cgroup supports to kill processes

On non-Linux ports ?

--
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: default init on non-Linux platforms

2014-02-20 Thread Ansgar Burchardt

On 02/20/2014 15:28, Thomas Goirand wrote:
 On 02/20/2014 09:02 PM, Tom H wrote:
 What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
 doesn't have?
 
 Just to name a few:
 - getting rid of the ugly LSB headers
 - cgroup supports to kill processes

I'm curious: does OpenRC allow processes to leave the cgroup? For
example, when killing the ssh service, I do not want to kill active
connections. With systemd, pam_systemd takes care of this. How does it
work on OpenRC?

 - Dependency caching system (so you wont have to wait for its
 calculation at next boot)

I thought the current sysvinit implementation with insserv in Debian
already does this. But I might be wrong.

 Also, we have an ALIVE UPSTREAM TEAM, and an evolving project, which is
 IMO important (is there anyone still working on sysv-rc apart from a few
 Debian maintainers? my understanding is: we're alone now...).

Doesn't it still use the (unmaintained?) sysvinit? But then, that's only
a part that probably doesn't need much maintainance anyway.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530616c8.2090...@debian.org

Re: default init on non-Linux platforms

2014-02-20 Thread Thomas Goirand

On 02/20/2014 10:45 PM, Didier 'OdyX' Raboud wrote:
 Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit :
 On 02/20/2014 09:02 PM, Tom H wrote:
 What features does sysvinit+openrc have that
 sysvinit+sysv-rc+insserv doesn't have?

 Just to name a few:
 - getting rid of the ugly LSB headers
 
 They might be ugly, but they encode the dependency tree; by what are 
 they replaced in OpenRC?

There's of course dependencies in OpenRC. You have the choice: either
you keep the LSB headers, either you write it the OpenRC way (IMO,
prefered...). In OpenRC, you just use functions of the openrc-run
interpreter. For exaample:

depend()
{
use dns
need localmount
after bootmisc ntp-client
}

The need expresses a Required-Start:, and use, a Should-Start:.

 - cgroup supports to kill processes
 
 On non-Linux ports ?

cgroup are optional, and obvious, not in use in kFreeBSD (see
/etc/rc.conf for its activation).

On 02/20/2014 10:52 PM, Ansgar Burchardt wrote:
 I'm curious: does OpenRC allow processes to leave the cgroup? For
 example, when killing the ssh service, I do not want to kill active
 connections. With systemd, pam_systemd takes care of this. How does it
 work on OpenRC?

Sorry, I don't know. You can try if you're curious! :)

On 02/20/2014 10:52 PM, Ansgar Burchardt wrote:
 Doesn't it still use the (unmaintained?) sysvinit? But then, that's
 only a part that probably doesn't need much maintainance anyway.

Correct, and I agree. The /sbin/init binary is anyway very small. As
much as I can tell, it is built only out of src/init.c and src/utmp.c,
which together represent 3162 lines of C code currently. That's antic
code from 1991! :)

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53062fb1.3000...@debian.org

Re: default init on non-Linux platforms

2014-02-20 Thread Russ Allbery

Ansgar Burchardt ans...@debian.org writes:
 On 02/20/2014 09:57, gregor herrmann wrote:
 On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:

 That package does currently depend on
 perl, though, which isn't appropriate for an essential package.
 ...  The dependency is because
 deb-systemd-helper uses a bunch of modules that are not currently in
 perl-core (File::Path, File::Basename, File::Find, File::Temp,
 Text::ParseWords, and Data::Dumper,

 I might be missing something but they all seem to be in perl core:

 I think Russ means they are not part of perl-base package, but provided
 by perl/perl-modules in Debian. So packages using them have to depend on
 the full perl package instead of the minimal perl-base package.

Yes, sorry, wrong package name.  I keep making that mistake.

 However this could be fixed by moving the additional modules to
 perl-base (increasing its size slightly) or changing the implementation
 to not use them.

Yes.  I'm not sure if we want to do that rather than just keeping that
program in a separate package from the stuff that has to be essential.
I'm not familiar with how high of a bar we set for including modules in
perl-base.

Some of those modules (File::Find, File::Temp, Text::ParseWords) are ones
where I'd be a little uncomfortable with open-coding the desired
functionality.  Getting those operations correct is tricky and requires
care, and it's best to use standard implementations that have been heavily
tested.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sirdn2i1@windlord.stanford.edu

Re: default init on non-Linux platforms

2014-02-20 Thread Russ Allbery

Ansgar Burchardt ans...@debian.org writes:
 On 02/20/2014 15:28, Thomas Goirand wrote:

 Also, we have an ALIVE UPSTREAM TEAM, and an evolving project, which is
 IMO important (is there anyone still working on sysv-rc apart from a
 few Debian maintainers? my understanding is: we're alone now...).

 Doesn't it still use the (unmaintained?) sysvinit? But then, that's only
 a part that probably doesn't need much maintainance anyway.

I believe that sysvinit and sysv-rc are both actively maintained by at
least Petter Reinholdsten and possibly also Roger Leigh and Werner Fink (I
haven't checked recent commit activity, but Petter has definitely been
doing new development on those packages), and that they consider
themselves to be upstream, not just Debian package maintainers.  I
wouldn't classify either as unmaintained upstream, although the level of
resources available is currently low compared to the other init systems
we've been discussing.

http://savannah.nongnu.org/projects/sysvinit is the upstream home page.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ob21n2aa@windlord.stanford.edu

Re: default init on non-Linux platforms

2014-02-20 Thread Ondřej Surý

On Thu, Feb 20, 2014, at 17:39, Thomas Goirand wrote:
 There's of course dependencies in OpenRC. You have the choice: either
 you keep the LSB headers, either you write it the OpenRC way (IMO,
 prefered...). In OpenRC, you just use functions of the openrc-run
 interpreter. For example:

Well, this is something I have been looking for...

If this can be made to work without the needed mumbo jumbo (see
below)... then it would solve the problem with migrating sysv-rc
scripts.

I have split openrc into openrc and openrc-sysv moving the conflicting
parts to openrc-sysv on my system, and it install just fine, but running
script with /sbin/openrc-run needs:

mkdir -p /run/openrc
touch /run/openrc/softlevel

and then it still doesn't work as expected:

root@howl:/etc/init.d# /etc/init.d/rsyslog start
 * WARNING: rsyslog is already starting

root@howl:/etc/init.d# /etc/init.d/rsyslog stop
 * ERROR: rsyslog stopped by something else

root@howl:/etc/init.d# /etc/init.d/rsyslog status
 * status: stopped

root@howl:/etc/init.d# ps uax | grep rsyslo[g]
root  6743  0.0  0.0  52592  1752 ?Ssl  20:28   0:00
/usr/sbin/rsyslogd -n -c5
root  6764  0.0  0.0   7768   856 pts/0S+   20:28   0:00 grep
rsyslog

Thomas, would it be possible to make openrc-run work even when the
openrc doesn't replace /etc/init.d/rc{,S}? Or does it need too much from
openrc infrastructure, so my idea is just too crazy?

O.
-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1392925038.31139.85827933.1da8f...@webmail.messagingengine.com

Re: default init on non-Linux platforms

2014-02-20 Thread heroxbd

Hey Ondřej,

Ondřej Surý ond...@sury.org writes:

 I have split openrc into openrc and openrc-sysv moving the conflicting
 parts to openrc-sysv on my system, and it install just fine, but running
 script with /sbin/openrc-run needs:

 mkdir -p /run/openrc
 touch /run/openrc/softlevel

 and then it still doesn't work as expected:

 root@howl:/etc/init.d# /etc/init.d/rsyslog start
  * WARNING: rsyslog is already starting

 root@howl:/etc/init.d# /etc/init.d/rsyslog stop
  * ERROR: rsyslog stopped by something else

 root@howl:/etc/init.d# /etc/init.d/rsyslog status
  * status: stopped

OpenRC needs a proper directory structure in /run/openrc to track the
status of services. It is handled by init.sh and friends, you may need
to hack that.

 root@howl:/etc/init.d# ps uax | grep rsyslo[g]
 root  6743  0.0  0.0  52592  1752 ?Ssl  20:28   0:00
 /usr/sbin/rsyslogd -n -c5
 root  6764  0.0  0.0   7768   856 pts/0S+   20:28   0:00 grep
 rsyslog

 Thomas, would it be possible to make openrc-run work even when the
 openrc doesn't replace /etc/init.d/rc{,S}? 

sure.

 Or does it need too much from openrc infrastructure, so my idea is
 just too crazy?

No, it not crazy. I am running OpenRC to manage services on the clusters
where I have only normal user privilege, it's in parallel to sysv-rc
like system of RHEL5. You might look into the MKPREFIX build option.

And out of curiosity, what are you trying to achieve here?

Cheers,
Benda

Re: default init on non-Linux platforms

2014-02-19 Thread Matthias Urlichs

Hi,

Thomas Goirand:
  [0] Can we haz a release name?
 
 It's been years that I've been asking that we have the release name a
 way sooner. Ideally, one release earlier, so that we can prepare for the
 new name soon enough (and not fix things during the freeze). But the
 release team doesn't seem to agree with this! :)
 
I'm all for going with zurg here.

This transition mentions jessie+1 so often that naming it now make sense.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

2014-02-19 Thread Chris Bannister

On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
 On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
  [0] Can we haz a release name?
  
 
 Sure. It's Debian 8.0, zurg. [0]
 
 Neil
 [0] Note: may be a lie.

Umm, Debian 9.0?

-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140219103708.GE28892@tal

Re: default init on non-Linux platforms

2014-02-19 Thread Neil McGovern

On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
 On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
  On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
   [0] Can we haz a release name?
   
  
  Sure. It's Debian 8.0, zurg. [0]
  
  Neil
  [0] Note: may be a lie.
 
 Umm, Debian 9.0?
 

For those who may not be following along at home, I'm no longer a
release manager. I don't get to pick release names. The use of 8.0 was
deliberate to try and make it clearer that I have no say in the matter.

Neil
-- 


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

2014-02-19 Thread Dimitri John Ledkov

On 19 February 2014 11:22, Neil McGovern ne...@debian.org wrote:
 On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
 On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
  On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
   [0] Can we haz a release name?
  
 
  Sure. It's Debian 8.0, zurg. [0]
 
  Neil
  [0] Note: may be a lie.

 Umm, Debian 9.0?


 For those who may not be following along at home, I'm no longer a
 release manager. I don't get to pick release names. The use of 8.0 was
 deliberate to try and make it clearer that I have no say in the matter.


But it's such a good name!

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/canbhluhsjcqzxh3l1yrzduzl6ahxwsurgjzyfgxzvkwmodm...@mail.gmail.com

Re: default init on non-Linux platforms

2014-02-19 Thread Michael Biebl

Am 18.02.2014 19:18, schrieb Didier 'OdyX' Raboud:
 Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
 On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
 On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional
 package?
 What is the opinion of other DDs? Is there anyone which would like
 to
 keep the old featureless sysv-rc?

 What problem does that solve?

 In this way, we'd have only 2 init systems to take care of, and we
 could start replacing init.d scripts by OpenRC runscripts *IF*
 there's a systemd service file.
 
 Yes. And three different daemon-starting syntaxes to manage the Wheezy-
 to-Jessie upgrades.
 
 Again, for Jessie, I don't think it's reasonable to change the default 
 init _and_ replace the common baseline. I, for one, am not going to 
 replace my awkward-but-working sysvinit scripts by anything but 
 systemd/upstart unit files and that is doomed to happen in jessie+1 [0].

I'd like to add that switching to openrc breaks the SysV/LSB support in
systemd. Openrc doesn't use the /etc/rc?.d/ directories to create the
symlinks which signal if a service is active for a given runlevel.
(those symlinks are created in /etc/runlevel/* afaics)

This means systemd doesn't consider the SysV/LSB init script as enabled
and won't start it on boot.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: default init on non-Linux platforms

2014-02-19 Thread Michael Biebl

Am 19.02.2014 00:52, schrieb Russ Allbery:
 Henrique de Moraes Holschuh h...@debian.org writes:
 
 They *HAVE* to be provided by the active init system.  They are an
 impedance matching layer (aka stable API) used by maintainer scripts to
 interface with the active init system.
 
 If you look at the existing implementation, you'll find that the version
 provided by sysv-rc already supports systemd, upstart, and sysv-rc itself.
 So this isn't precisely true.  If we stick with the current model, then
 some (probably essential) package just needs to provide those
 implementations and accept patches to work with new init systems, but each
 init system doesn't need to provide its own version.
 
 There are some advantages to providing only one version with knowledge of
 all of the init systems given that we're supporting init system switching,
 and therefore may need to set up state for init systems that aren't
 currently running so that switching can work properly.  A good example is
 registering an init script with insserv so that the correct S and K links
 are created even if the system is currently booted with a different init
 system.

If you look at e.g. update-rc.d enable|disable, it currently has support
for systemd, upstart and sysv-rc. So whenever you enable a service, this
state is kept in sync across the different init systems (assuming the
service in question ships native support for other init systems).

I don't find equivalent functionality in openrc's implementation of
update-rc.d



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: default init on non-Linux platforms

2014-02-19 Thread Thomas Goirand

On 02/19/2014 10:44 PM, Michael Biebl wrote:
 I'd like to add that switching to openrc breaks the SysV/LSB support in
 systemd. Openrc doesn't use the /etc/rc?.d/ directories to create the
 symlinks which signal if a service is active for a given runlevel.
 (those symlinks are created in /etc/runlevel/* afaics)
 
 This means systemd doesn't consider the SysV/LSB init script as enabled
 and won't start it on boot.

Oh, that's interesting!

First, yes, OpenRC uses /etc/runlevel, with the folders below that being
the *names* of the runlevel (which IMO is a way more user friendly than
just numbers). FYI, we have: shutdown=0, recovery=1, reboot=6, and
everything-else=default. So we do have these 4 directory names, and
OpenRC doesn't care about /etc/rc?.d.

Could you expand the above text and give a bit more explanations /
details? :)

So, systemd is still using /etc/rc?.d. Could you tell exactly what it
uses out of /etc/rc?.d, and what for? Does it only needs to see them as
S??script-name in runlevel 2 or 4 (or whatever it uses...)?

If systemd needs links in /etc/rcX.d, then I think it should be possible
to hack something.

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304c91a.1090...@debian.org

Re: default init on non-Linux platforms

2014-02-19 Thread Ondřej Surý

Dimitri,

On Wed, Feb 19, 2014, at 12:57, Dimitri John Ledkov wrote:
 On 19 February 2014 11:22, Neil McGovern ne...@debian.org wrote:
  On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
  On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
   On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
[0] Can we haz a release name?
   
  
   Sure. It's Debian 8.0, zurg. [0]
  
   Neil
   [0] Note: may be a lie.
 
  Umm, Debian 9.0?
 
 
  For those who may not be following along at home, I'm no longer a
  release manager. I don't get to pick release names. The use of 8.0 was
  deliberate to try and make it clearer that I have no say in the matter.
 
 
 But it's such a good name!

are you aware that media are already quoting your blogpost as official
announcement of next Debian codename?

O.
-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1392823700.31129.85290293.71ac1...@webmail.messagingengine.com

Re: default init on non-Linux platforms

2014-02-19 Thread Dimitri John Ledkov

On 19 February 2014 15:28, Ondřej Surý ond...@sury.org wrote:
 Dimitri,

 On Wed, Feb 19, 2014, at 12:57, Dimitri John Ledkov wrote:
 On 19 February 2014 11:22, Neil McGovern ne...@debian.org wrote:
  On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
  On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
   On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
[0] Can we haz a release name?
   
  
   Sure. It's Debian 8.0, zurg. [0]
  
   Neil
   [0] Note: may be a lie.
 
  Umm, Debian 9.0?
 
 
  For those who may not be following along at home, I'm no longer a
  release manager. I don't get to pick release names. The use of 8.0 was
  deliberate to try and make it clearer that I have no say in the matter.
 

 But it's such a good name!

 are you aware that media are already quoting your blogpost as official
 announcement of next Debian codename?


Nah, wasn't aware =) I blame Neil, I thought he still was a release manager ;-)
Any reason, not to make it official? =)

-- 
Regards,

Dimitri.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANBHLUjk=szx4ztfxwzhjnyxptgeovtqtbesa_cf_dnuqyj...@mail.gmail.com

Re: default init on non-Linux platforms

2014-02-19 Thread Simon McVittie

On 19/02/14 15:09, Thomas Goirand wrote:
 First, yes, OpenRC uses /etc/runlevel, with the folders below that being
 the *names* of the runlevel (which IMO is a way more user friendly than
 just numbers). FYI, we have: shutdown=0, recovery=1, reboot=6, and
 everything-else=default. So we do have these 4 directory names, and
 OpenRC doesn't care about /etc/rc?.d.

Similar to systemd's multi-user.target etc. (which are made to depend on
native systemd units), then. However, systemd still needs to know
whether an LSB init script with no corresponding systemd unit should be
started or not, which it does by looking in /etc/rcX.d (I think it
assuems that anything started in any of rc[2345].d should be included in
multi-user.target).

 If systemd needs links in /etc/rcX.d, then I think it should be possible
 to hack something.

I suspect the right thing would be to share one implementation of
update-rc.d(8), invoke-rc.d(8) and possibly service(8) between all
supported init implementations, provided by either src:sysvinit or
src:init-system-helpers. The implementations in sysv-rc and
sysvinit-utils already seem to support sysv-rc[1], systemd and Upstart;
teaching them about OpenRC shouldn't be rocket science.

This has the advantage that if you install a daemon while your init is
sysvinit/sysv-rc, enable and/or disable it, then switch to systemd or
OpenRC and reboot, that daemon remains enabled or disabled (as appropriate).

S

[1] and probably file-rc for that matter


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304d35e.20...@debian.org

Re: default init on non-Linux platforms

2014-02-19 Thread The Wanderer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:

 On 19 February 2014 15:28, Ondřej Surý ond...@sury.org wrote:
 
 Dimitri,

 are you aware that media are already quoting your blogpost as
 official announcement of next Debian codename?
 
 Nah, wasn't aware =) I blame Neil, I thought he still was a release
 manager ;-) Any reason, not to make it official? =)

Well, back in 2002 there was a probably-joking sort-of decision that
zurg should be the codename of the release where the Hurd and *BSD
ports were fully ready [1]. Given that we seem to be moving more towards
dropping ports than finalizing them at the moment, using the name zurg
would not seem to be in keeping with that idea.

I like the idea (and the method of choosing, and of announcing, it)
otherwise, though.


[1] https://lists.debian.org/debian-devel/2002/07/msg01139.html

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTBNSBAAoJEASpNY00KDJrxTkP/2JtWJDGwrw+EXNaUBE5fFv+
zjWMPUqmCZgvaS/LUe8aiwbPUGXXy18pyIQwsHH30XPcouCQTbX7K1I8PuUekMc1
E4axQ6F5/aFZHki1n1VxWqW3VUxPU+hDP4CpPr+OymSQDkXduMir2WXYx1JMyYKR
405zV2NjirFuwS9ldD/EaEA5zCXAK2KSw1KG3KVRJN3N/r2/y1nxomJ9B6lMuUJT
RrjlCg3DYuwWQGMDHuA3OAnIxRP/qI2EkNp5qPCY6zAsZf4co8PDrjsC/4cx4AVo
Zqu6FDkR+vROzhF7+016s2buVUsGmExDysY1dNaflXGB3A0jpIBcEQ0qxXuYbR1a
Eo0CSn34+7DuMCeIYslW7vtEviAH4K5gxt4kAQTqU65OVGGEUDCaj3T8VwQ0bb5l
BD5YryZA/bXdBXVZm3geGa9Ft41Bg2WGqd5G1/muvmc+yP0oocWmTnDJaEqBSDaH
sp5YvVVXgK7G7azMvCjpL0M2gXAoaDcPjsoG/9D8jEThnVshk3fmu1EgsCxnecR+
qY1fBhCP88GpSXSc2jb0cPvGFIZJSH6V7q2r9ZUniT9wsL53rq5mGnM6soM+Gn/c
uz+5IK2gc5yO1o/besgkGGFd3RbIrYEvFOqjfdJIqexV4Lrw2r8LH1rOX66gaSB1
4Ephwd895xZzC/5wP4Tj
=wIwk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304d481.9000...@fastmail.fm

Re: default init on non-Linux platforms

2014-02-19 Thread Dimitri John Ledkov

On 19 February 2014 15:57, The Wanderer wande...@fastmail.fm wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:

On 19 February 2014 15:28, Ondřej Surý ond...@sury.org wrote:

Dimitri,

are you aware that media are already quoting your blogpost as
official announcement of next Debian codename?

Nah, wasn't aware =) I blame Neil, I thought he still was a release
manager ;-) Any reason, not to make it official? =)

Well, back in 2002 there was a probably-joking sort-of decision that
zurg should be the codename of the release where the Hurd and *BSD
ports were fully ready [1]. Given that we seem to be moving more towards
dropping ports than finalizing them at the moment, using the name zurg
would not seem to be in keeping with that idea.

I like the idea (and the method of choosing, and of announcing, it)
otherwise, though.

To be honest Zurg is living up to it's expectations. kFreeBSD is
looking very solid on jessie already, and it can only get better by
Zurg time. Initial porting work is done, and now work is mostly put
into polishing and providing new features. It really is something i'm
comfortable running as my main server. And given Zurg's ambitious
plans drafted today the name is both suitable and telling as predicted
back then.

And if scope is limitted to virtual machines / cloud instances - Hurd
also looks very good.

--
Regards,

Dimitri.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANBHLUiB==jdfc1sjchgnitacorzraa966cwfu6vuagaekq...@mail.gmail.com

Re: default init on non-Linux platforms

2014-02-19 Thread Thomas Goirand

On 02/19/2014 10:47 PM, Michael Biebl wrote:
 Am 19.02.2014 00:52, schrieb Russ Allbery:
 Henrique de Moraes Holschuh h...@debian.org writes:

 They *HAVE* to be provided by the active init system.  They are an
 impedance matching layer (aka stable API) used by maintainer scripts to
 interface with the active init system.

 If you look at the existing implementation, you'll find that the version
 provided by sysv-rc already supports systemd, upstart, and sysv-rc itself.
 So this isn't precisely true.  If we stick with the current model, then
 some (probably essential) package just needs to provide those
 implementations and accept patches to work with new init systems, but each
 init system doesn't need to provide its own version.

 There are some advantages to providing only one version with knowledge of
 all of the init systems given that we're supporting init system switching,
 and therefore may need to set up state for init systems that aren't
 currently running so that switching can work properly.  A good example is
 registering an init script with insserv so that the correct S and K links
 are created even if the system is currently booted with a different init
 system.
 
 If you look at e.g. update-rc.d enable|disable, it currently has support
 for systemd, upstart and sysv-rc. So whenever you enable a service, this
 state is kept in sync across the different init systems (assuming the
 service in question ships native support for other init systems).
 
 I don't find equivalent functionality in openrc's implementation of
 update-rc.d

How come? I just took what was in the sysinit package! Or probably, what
you are talking about is new features, which I should merge it back into
the OpenRC version?

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304e46b.8050...@debian.org

Re: default init on non-Linux platforms

2014-02-19 Thread Thomas Goirand

On 02/19/2014 11:53 PM, Simon McVittie wrote:
 I suspect the right thing would be to share one implementation of
 update-rc.d(8), invoke-rc.d(8) and possibly service(8) between all
 supported init implementations, provided by either src:sysvinit or
 src:init-system-helpers.

Surprisingly, service is shared among all init systems (it's in
sysvinit-utils), while the other 2 are not.

I agree we should have a common interface and make sure one daemon
remains enabled / disabled in all init systems.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304e53b.9050...@debian.org

Re: default init on non-Linux platforms

2014-02-19 Thread Matthias Urlichs

Hi,

The Wanderer:
  Nah, wasn't aware =) I blame Neil, I thought he still was a release
  manager ;-) Any reason, not to make it official? =)
 
 Well, back in 2002 there was a probably-joking sort-of decision that
 zurg should be the codename of the release where the Hurd and *BSD
 ports were fully ready [1].

Only 14 years late, then. (Assuming it'll be ready sometime in 2016.)

Let's put it this way: we're unlikely to exceed that delay any time soon.

 I like the idea (and the method of choosing, and of announcing, it)
 otherwise, though.

+1

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Press updates [Was: Re: default init on non-Linux platforms]

2014-02-19 Thread Neil McGovern

On Wed, Feb 19, 2014 at 03:45:12PM +, Dimitri John Ledkov wrote:
 On 19 February 2014 15:28, Ondřej Surý ond...@sury.org wrote:
  are you aware that media are already quoting your blogpost as official
  announcement of next Debian codename?
 
 
 Nah, wasn't aware =) I blame Neil, I thought he still was a release manager 
 ;-)
 Any reason, not to make it official? =)
 

You should read your lovely bits mails more carefully then :) I also
wouldn't call phoronix the media. And on a slight tangent, I'd always
welcome more people who are interested in the press and publicity team
:)

Neil
-- 


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

2014-02-19 Thread Kevin Chadwick

previously on this list Thomas Goirand contributed:

 So, systemd is still using /etc/rc?.d. Could you tell exactly what it
 uses out of /etc/rc?.d, and what for? Does it only needs to see them as
 S??script-name in runlevel 2 or 4 (or whatever it uses...)?
 
 If systemd needs links in /etc/rcX.d, then I think it should be possible
 to hack something.

One of the main things I like about OpenRC and especially OpenBSDs rc
system is that you can modify the files directly intuitively.

The main thing I hate about the current system is those links and them
requiring a tool to edit them in any timely fashion. Almost as much as
the huge commandlines needed to do so for systemd without it's tools
or for things it's tools can't or couldn't do at the time I tested it
out, if I remember rightly to do with
org.??? lines.

Do people use all those runlevels?

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/494637.19636...@smtp114.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

2014-02-19 Thread Tollef Fog Heen

]] Thomas Goirand 

 How come? I just took what was in the sysinit package! Or probably, what
 you are talking about is new features, which I should merge it back into
 the OpenRC version?

It's probably better to just contribute your changes to the sysv-rc
version and so make that one able to manage openrc in addition to the
others it already knows how to.  No point in forking it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2ppmi4cvu@rahvafeir.err.no

Re: default init on non-Linux platforms

2014-02-19 Thread heroxbd

Hi Tollef,

Tollef Fog Heen tfh...@err.no writes:

 It's probably better to just contribute your changes to the sysv-rc
 version and so make that one able to manage openrc in addition to the
 others it already knows how to.  No point in forking it.

Forking was a decision made by me in the early phase of packaging
OpenRC. At that time I referred to the way file-rc handled update-rc.d
as in

 sysvinit: /usr/share/sysvinit/update-rc.d

A central package providing update-rc.d and invoke-rc.d is nice. Though
it should not be sysv-rc, which OpenRC is intending to replace.

Cheers,
Benda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86a9dmbbtp@moguhome00.in.awa.tohoku.ac.jp

Re: default init on non-Linux platforms

2014-02-19 Thread Russ Allbery

hero...@gentoo.org writes:

 Forking was a decision made by me in the early phase of packaging
 OpenRC. At that time I referred to the way file-rc handled update-rc.d
 as in

  sysvinit: /usr/share/sysvinit/update-rc.d

 A central package providing update-rc.d and invoke-rc.d is nice. Though
 it should not be sysv-rc, which OpenRC is intending to replace.

One possibility would be to move those programs to init-system-helpers,
since that is, after all, the point of that package (even if right now
it's only used for systemd glue).  That package does currently depend on
perl, though, which isn't appropriate for an essential package.  I'm not
sure the best way to approach that.  The dependency is because
deb-systemd-helper uses a bunch of modules that are not currently in
perl-core (File::Path, File::Basename, File::Find, File::Temp,
Text::ParseWords, and Data::Dumper, although the last is only used for
debugging and could be loaded on demand if available and skipped
otherwise).

File::Path and File::Basename can be easily replaced with some short
functions and simple regexes, but the rest are a bit harder to replace.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r46y8i63@windlord.stanford.edu

Re: default init on non-Linux platforms

On 02/18/2014 10:15 PM, Ondřej Surý wrote:
 Hi,
 
 I don't really want to open another can of worms, but what's the opinion
 of non-Linux ports maintainers on default init?
 
 Or maybe I should turn it another way:
 
 If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
 
 Depends: systemd | openrc
 
 if I want to get rid of non-declarative init scripts in my daemon
 packages?
 
 O.

I'd like to widen this topic.

We're not there yet (I still need to do some more tests with Hurd, and
fix a few problems), but I will soon upload OpenRC to Sid.

Once I consider OpenRC ready for it, would it be ok to just replace
sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
What is the opinion of other DDs? Is there anyone which would like to
keep the old featureless sysv-rc?

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53037464.4030...@debian.org

Re: default init on non-Linux platforms

2014-02-18 Thread Jonathan Dowland

On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
 What is the opinion of other DDs? Is there anyone which would like to
 keep the old featureless sysv-rc?

What problem does that solve?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218151029.ga2...@bryant.redmars.org

Re: default init on non-Linux platforms

2014-02-18 Thread Guus Sliepen

On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:

 On 02/18/2014 10:15 PM, Ondřej Surý wrote:
[...]
  If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
  
  Depends: systemd | openrc
  
  if I want to get rid of non-declarative init scripts in my daemon
  packages?
[...]
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
 What is the opinion of other DDs? Is there anyone which would like to
 keep the old featureless sysv-rc?

My opinion is that maintainers should still provide sysv init scripts until it
is decided that Debian does not support sysvinit any more. The TC decided that
systemd will be the default init system on Linux, not that it would be the only
init system.

Dropping support for sysv init scripts now means that you are burning the
bridge before you finished crossing it.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen g...@debian.org


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

2014-02-18 Thread Kurt Roeckx

On Tue, Feb 18, 2014 at 03:15:24PM +0100, Ondrej Surý wrote:
 Hi,
 
 I don't really want to open another can of worms, but what's the opinion
 of non-Linux ports maintainers on default init?
 
 Or maybe I should turn it another way:
 
 If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
 
 Depends: systemd | openrc
 
 if I want to get rid of non-declarative init scripts in my daemon
 packages?

I think that's going to fail on upgrade when sysvinit it still
running as init.


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218151855.ga12...@roeckx.be

Re: default init on non-Linux platforms

2014-02-18 Thread Andrew Shadura

Hello,

On 18 February 2014 16:08, Guus Sliepen g...@debian.org wrote:
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
 What is the opinion of other DDs? Is there anyone which would like to
 keep the old featureless sysv-rc?

 My opinion is that maintainers should still provide sysv init scripts until it
 is decided that Debian does not support sysvinit any more. The TC decided that
 systemd will be the default init system on Linux, not that it would be the
 only init system.

 Dropping support for sysv init scripts now means that you are burning the
 bridge before you finished crossing it.

OpenRC, if properly baked, fully supports traditional initscripts, so
nothing burns. I guess Thomas is working on baking OpenRC the right
way :)

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cacujmdp+pckq-lvvkgdfnbfegmf+rhwdwgxgbmp3830k4mt...@mail.gmail.com

Re: default init on non-Linux platforms

2014-02-18 Thread Didier 'OdyX' Raboud

Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit :
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
 What is the opinion of other DDs? Is there anyone which would like to
 keep the old featureless sysv-rc?

I think we should focus on one init system change at a time.

Having the good-old sysvinit setup still working in a satisfactory 
manner is nice while preparing Jessie: that's what Wheezy has and 
therefore has to be supported to upgrade to Jessie (think partial 
upgrades, full-upgrade-not-rebooted-yet, etc etc). When testing crazy 
stuff with systemd, I know I can always fallback to sysvinit if I broke 
any .socket or .service unit I'm working on. It will be slower and feel 
old, but would most certainly boot and provide me with comfortable ways 
to debug. If that was changed to OpenRC, we'd exchange the sysvinit 
safety net that all got to know in exchange for a brand new safety net 
that we don't really know yet.

Moving to OpenRC as the secondary init for Jessie looks like changing 
the two wheels of a bike at the same time. I'd widely prefer to keep 
sysvinit (as old it might feel) for Jessie, especially as transition 
point from Wheezy and have these discussions again after Jessie is 
released.

That shouldn't stop you from providing the best OpenRC integration in 
Debian, be it for the ports or in preparation for jessie+1.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: default init on non-Linux platforms

2014-02-18 Thread Simon McVittie

On 18/02/14 14:15, Ondřej Surý wrote:
 If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
 
 Depends: systemd | openrc
 
 if I want to get rid of non-declarative init scripts in my daemon
 packages?

I don't think that's going to be a good migration path from wheezy to
jessie. For instance, suppose your daemon is ondrejd. After upgrading
ondrejd/wheezy to ondrejd/jessie, but before rebooting into jessie, it's
still necessary for sysvinit and sysv-rc to be able to stop ondrejd; and
the postinst must succeed, which with debhelper's current dh_installinit
snippets means it's still necessary for sysvinit and sysv-rc to be able
to *start* ondrejd, too (although degraded operation would be OK).

(Depends: systemd doesn't give you systemd-as-pid-1 as a replacement for
sysvinit, anyway; that's systemd-sysv.)

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5303815d.4010...@debian.org

Re: default init on non-Linux platforms

On 02/18/2014 11:08 PM, Guus Sliepen wrote:
 On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
 
 On 02/18/2014 10:15 PM, Ondřej Surý wrote:
 [...]
 If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:

 Depends: systemd | openrc

 if I want to get rid of non-declarative init scripts in my daemon
 packages?
 [...]
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
 What is the opinion of other DDs? Is there anyone which would like to
 keep the old featureless sysv-rc?
 
 My opinion is that maintainers should still provide sysv init scripts until it
 is decided that Debian does not support sysvinit any more. The TC decided that
 systemd will be the default init system on Linux, not that it would be the 
 only
 init system.
 
 Dropping support for sysv init scripts now means that you are burning the
 bridge before you finished crossing it.

You are IMO missing the point. I'm not proposing to drop support for
init scripts, but remove sysv-rc. That's very different! We could
continue to have init scripts but have OpenRC to use them.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5303831c.4020...@debian.org

Re: default init on non-Linux platforms

2014-02-18 Thread Jonathan Dowland

On Tue, Feb 18, 2014 at 11:58:20PM +0800, Thomas Goirand wrote:
 You are IMO missing the point. I'm not proposing to drop support for
 init scripts, but remove sysv-rc. That's very different! We could
 continue to have init scripts but have OpenRC to use them.

Although I'm still not sure what problem you are trying to solve, I
would suggest explicitly CCing pkg-sysvinit-devel (the sysvinit
maintainers).

-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218161838.gb2...@bryant.redmars.org

Re: default init on non-Linux platforms

2014-02-18 Thread Christoph Egger

Hi!

Ondřej Surý ond...@sury.org writes:
 I don't really want to open another can of worms, but what's the opinion
 of non-Linux ports maintainers on default init?

  Hm so why was none of the ports list Cc-ed on this mail? There is
active discussion [0] between hurd and bsd people were we want to go
now.

 Or maybe I should turn it another way:

 If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:

 Depends: systemd | openrc

 if I want to get rid of non-declarative init scripts in my daemon
 packages?

  As others have said already, sysv init is hardly going away *for*
*jessie* (if for upgrades alone). This positions seems to clearly be
supported by systemd maintainers as well (I remember particularly
discussing things along these lines with e.g. Michael Stapelberg at
Debconf).

  Christoph

[0] 52e82fac.2070...@pyro.eu.org and followups
-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bny4ie02@anonymous.siccegge.de

Re: default init on non-Linux platforms

On 02/18/2014 11:38 PM, Didier 'OdyX' Raboud wrote:
 Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit :
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
 What is the opinion of other DDs? Is there anyone which would like to
 keep the old featureless sysv-rc?
 
 I think we should focus on one init system change at a time.
 
 Having the good-old sysvinit setup still working in a satisfactory 
 manner is nice while preparing Jessie: that's what Wheezy has and 
 therefore has to be supported to upgrade to Jessie (think partial 
 upgrades, full-upgrade-not-rebooted-yet, etc etc). When testing crazy 
 stuff with systemd, I know I can always fallback to sysvinit if I broke 
 any .socket or .service unit I'm working on. It will be slower and feel 
 old, but would most certainly boot and provide me with comfortable ways 
 to debug. If that was changed to OpenRC, we'd exchange the sysvinit 
 safety net that all got to know in exchange for a brand new safety net 
 that we don't really know yet.
 
 Moving to OpenRC as the secondary init for Jessie looks like changing 
 the two wheels of a bike at the same time. I'd widely prefer to keep 
 sysvinit (as old it might feel) for Jessie, especially as transition 
 point from Wheezy and have these discussions again after Jessie is 
 released.
 
 That shouldn't stop you from providing the best OpenRC integration in 
 Debian, be it for the ports or in preparation for jessie+1.
 
 Cheers,
 OdyX

Didier, what you are saying above make sense, I haven't really thought
about a timeline though.

If everyone agrees to have Jessie+1 as a target for sysv-rc deprecation,
that's fine to me.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53038a6e.3010...@debian.org

Re: default init on non-Linux platforms

2014-02-18 Thread Jonathan Dowland

On Tue, Feb 18, 2014 at 05:26:05PM +0100, Christoph Egger wrote:
   Hm so why was none of the ports list Cc-ed on this mail? There is
 active discussion [0] between hurd and bsd people were we want to go
 now.

Likewise perhaps pkg-sysvinit-devel should be copied into all such
discussions (copied here)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218165441.gc2...@bryant.redmars.org

Re: default init on non-Linux platforms

On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
 On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
 What is the opinion of other DDs? Is there anyone which would like to
 keep the old featureless sysv-rc?
 
 What problem does that solve?

In this way, we'd have only 2 init systems to take care of, and we could
start replacing init.d scripts by OpenRC runscripts *IF* there's a
systemd service file. Otherwise, we have to keep init.d scripts just in
case someone is running sysv-rc. So keeping sysv-rc would block progress
and force anyone to keep writing/maintaining init.d LSB header scripts.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530390a7.1050...@debian.org

Re: default init on non-Linux platforms

On 02/18/2014 11:38 PM, Didier 'OdyX' Raboud wrote:
 Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit :
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
 What is the opinion of other DDs? Is there anyone which would like to
 keep the old featureless sysv-rc?
 
 I think we should focus on one init system change at a time.
 
 Having the good-old sysvinit setup still working in a satisfactory 
 manner is nice while preparing Jessie: that's what Wheezy has and 
 therefore has to be supported to upgrade to Jessie (think partial 
 upgrades, full-upgrade-not-rebooted-yet, etc etc). When testing crazy 
 stuff with systemd, I know I can always fallback to sysvinit if I broke 
 any .socket or .service unit I'm working on. It will be slower and feel 
 old, but would most certainly boot and provide me with comfortable ways 
 to debug. If that was changed to OpenRC, we'd exchange the sysvinit 
 safety net that all got to know in exchange for a brand new safety net 
 that we don't really know yet.
 
 Moving to OpenRC as the secondary init for Jessie looks like changing 
 the two wheels of a bike at the same time. I'd widely prefer to keep 
 sysvinit (as old it might feel) for Jessie, especially as transition 
 point from Wheezy and have these discussions again after Jessie is 
 released.
 
 That shouldn't stop you from providing the best OpenRC integration in 
 Debian, be it for the ports or in preparation for jessie+1.
 
 Cheers,
 OdyX

Actually, thinking about it a 2nd time, I think there would be a major
drawback in delaying to Jessie +1. If we decide that sysv-rc goes away,
then starting at the Jessie release, we don't have to care anymore about
LSB header scripts. Meaning that we could write systemd service files,
plus OpenRC runscripts (for those who cares about OpenRC, or our
non-linux ports).

If we delay it, this means that we'd have to keep maintaining LSB header
scripts in Sid for all the life of Jessie (for those who cares about
non-linux ports or having OpenRC / sysv-rc support).

Thoughts anyone?

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53039439.4060...@debian.org

Re: default init on non-Linux platforms

2014-02-18 Thread Gergely Nagy

Thomas Goirand z...@debian.org writes:

 Actually, thinking about it a 2nd time, I think there would be a major
 drawback in delaying to Jessie +1. If we decide that sysv-rc goes away,
 then starting at the Jessie release, we don't have to care anymore about
 LSB header scripts. Meaning that we could write systemd service files,
 plus OpenRC runscripts (for those who cares about OpenRC, or our
 non-linux ports).

 If we delay it, this means that we'd have to keep maintaining LSB header
 scripts in Sid for all the life of Jessie (for those who cares about
 non-linux ports or having OpenRC / sysv-rc support).

 Thoughts anyone?

From a maintainer PoV, I already maintain sysvinit scripts for wheezy,
and upstream, they will have to be maintained for the forseeable future
anyway, so maintaining it for Jessie is exactly zero work on my part.

Adding OpenRC to the mix (something I'm not familiar with, and I'm not
really interested in getting to know better, either) is an extra burden
I wouldn't want to do myself. I wouldn't say no to a patch adding an
OpenRC runscript, of course, but I'd rather not do it myself.

-- 
|8]

P.S.: If you're curious, and would like to send OpenRC runscript
patches, syslog-ng-core is the single package in the archive where I
maintain a sysvinit script. ;)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877g8stjem.fsf@algernon.balabit

Re: default init on non-Linux platforms

2014-02-18 Thread Didier 'OdyX' Raboud

Le mercredi, 19 février 2014, 01.11:21 Thomas Goirand a écrit :
 Actually, thinking about it a 2nd time, I think there would be a major
 drawback in delaying to Jessie +1. If we decide that sysv-rc goes
 away, then starting at the Jessie release, we don't have to care
 anymore about LSB header scripts. Meaning that we could write systemd
 service files, plus OpenRC runscripts (for those who cares about
 OpenRC, or our non-linux ports).
 
 If we delay it, this means that we'd have to keep maintaining LSB
 header scripts in Sid for all the life of Jessie (for those who cares
 about non-linux ports or having OpenRC / sysv-rc support).

I don't think that's true. If we decide that sysvinit scripts (hence LSB 
headers) have to be supported in jessie but are deprecated, then 
jessie+1 can start to drop them completely (given reasonable replacement 
for non-init defaults of course). Dropping them in the jessie suite 
would complicate the upgrade path from Wheezy for no reason that I would 
value high enough.

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4440019.su1Rqjt91a@gyllingar

Re: default init on non-Linux platforms

2014-02-18 Thread Didier 'OdyX' Raboud

Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
 On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
  On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
  Once I consider OpenRC ready for it, would it be ok to just replace
  sysv-rc by OpenRC, and transform sysv-rc into a transitional
  package?
  What is the opinion of other DDs? Is there anyone which would like
  to
  keep the old featureless sysv-rc?
  
  What problem does that solve?
 
 In this way, we'd have only 2 init systems to take care of, and we
 could start replacing init.d scripts by OpenRC runscripts *IF*
 there's a systemd service file.

Yes. And three different daemon-starting syntaxes to manage the Wheezy-
to-Jessie upgrades.

Again, for Jessie, I don't think it's reasonable to change the default 
init _and_ replace the common baseline. I, for one, am not going to 
replace my awkward-but-working sysvinit scripts by anything but 
systemd/upstart unit files and that is doomed to happen in jessie+1 [0].

Cheers,
OdyX

[0] Can we haz a release name?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2536787.IXIK3uYTH8@gyllingar

Re: default init on non-Linux platforms

2014-02-18 Thread Neil McGovern

On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
 [0] Can we haz a release name?
 

Sure. It's Debian 8.0, zurg. [0]

Neil
[0] Note: may be a lie.


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

2014-02-18 Thread Tollef Fog Heen

]] Thomas Goirand 


 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional package?

No, update-rc.d and invoke-rc.d still need to be provided by something.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2r4706yda@rahvafeir.err.no

Re: default init on non-Linux platforms

2014-02-18 Thread Andrew Shadura

Hello,

On Tue, 18 Feb 2014 19:59:13 +0100
Tollef Fog Heen tfh...@err.no wrote:

  Once I consider OpenRC ready for it, would it be ok to just replace
  sysv-rc by OpenRC, and transform sysv-rc into a transitional
  package?
 
 No, update-rc.d and invoke-rc.d still need to be provided by
 something.
 
OpenRC provides them.


-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218200708.6965c22a@ileemo

Re: default init on non-Linux platforms

2014-02-18 Thread Adam Borowski

On Wed, Feb 19, 2014 at 01:11:21AM +0800, Thomas Goirand wrote:
 Actually, thinking about it a 2nd time, I think there would be a major
 drawback in delaying to Jessie +1. If we decide that sysv-rc goes away,
 then starting at the Jessie release, we don't have to care anymore about
 LSB header scripts. Meaning that we could write systemd service files,
 plus OpenRC runscripts (for those who cares about OpenRC, or our
 non-linux ports).

Idea: someone is working on a service-runscript interpreter, for a subset
of common functionality.  If that tool could have a validator that returns
ok if there's no unsupported stanza, what about running that validator in
lintian and screaming if validation fails but there is no runscript?

This way, there'd be three kinds of packages:
* LSB only
* service that's palatable for OpenRC
* service + runscript

This would greatly simplify preparing for deprecation of sysv-rc.  Hopefully
somewhere to the tune of 90-95% packages having just one daemon definition.
Such a reduction of work could make dropping sysv-rc in jessie viable.

 If we delay it, this means that we'd have to keep maintaining LSB header
 scripts in Sid for all the life of Jessie (for those who cares about
 non-linux ports or having OpenRC / sysv-rc support).

If we need to suffer systemd but can't use the main benefit of new-style
init systems, what the whole brouchacha was for?  As OpenRC is supposed to
be a drop-in replacement, and upstart has dropped the towel, migrating by
Jessie would allow supporting only two init systems by Zurg¹ with nothing
but 1.05 declarative definition per daemon package.


[¹]. What do you mean, neilm doesn't get to name jessie+1?
-- 
A tit a day keeps the vet away.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218220732.gb31...@angband.pl

[OT]: zurg (was Re: default init on non-Linux platforms)

2014-02-18 Thread gustavo panizzo gfa

On 02/18/2014 03:31 PM, Neil McGovern wrote:
 On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
 [0] Can we haz a release name?

 Sure. It's Debian 8.0, zurg. [0]
finally one of the 'bad' guys!

[*]  as a release, sid don't apply

 Neil
 [0] Note: may be a lie.


-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5303dbe1.1050...@zumbi.com.ar

Re: default init on non-Linux platforms

2014-02-18 Thread Henrique de Moraes Holschuh

On Tue, 18 Feb 2014, Tollef Fog Heen wrote:
  Once I consider OpenRC ready for it, would it be ok to just replace
  sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
 
 No, update-rc.d and invoke-rc.d still need to be provided by something.

They *HAVE* to be provided by the active init system.  They are an impedance
matching layer (aka stable API) used by maintainer scripts to interface with
the active init system.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218234420.ga17...@khazad-dum.debian.net

Re: default init on non-Linux platforms

2014-02-18 Thread Russ Allbery

Henrique de Moraes Holschuh h...@debian.org writes:

 They *HAVE* to be provided by the active init system.  They are an
 impedance matching layer (aka stable API) used by maintainer scripts to
 interface with the active init system.

If you look at the existing implementation, you'll find that the version
provided by sysv-rc already supports systemd, upstart, and sysv-rc itself.
So this isn't precisely true.  If we stick with the current model, then
some (probably essential) package just needs to provide those
implementations and accept patches to work with new init systems, but each
init system doesn't need to provide its own version.

There are some advantages to providing only one version with knowledge of
all of the init systems given that we're supporting init system switching,
and therefore may need to set up state for init systems that aren't
currently running so that switching can work properly.  A good example is
registering an init script with insserv so that the correct S and K links
are created even if the system is currently booted with a different init
system.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bny4ou68@windlord.stanford.edu

Re: default init on non-Linux platforms

2014-02-18 Thread Henrique de Moraes Holschuh

On Tue, 18 Feb 2014, Russ Allbery wrote:
 Henrique de Moraes Holschuh h...@debian.org writes:
  They *HAVE* to be provided by the active init system.  They are an
  impedance matching layer (aka stable API) used by maintainer scripts to
  interface with the active init system.
 
 If you look at the existing implementation, you'll find that the version
 provided by sysv-rc already supports systemd, upstart, and sysv-rc itself.
 So this isn't precisely true.  If we stick with the current model, then
 some (probably essential) package just needs to provide those

Hmm, we can provide one, yes.  Probably in sysvinit-utils, which already has
some important tools that are not strictly related to sysvinit itself.

 There are some advantages to providing only one version with knowledge of
 all of the init systems given that we're supporting init system switching,
 and therefore may need to set up state for init systems that aren't
 currently running so that switching can work properly.  A good example is
 registering an init script with insserv so that the correct S and K links
 are created even if the system is currently booted with a different init
 system.

I agree.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140219000552.ga17...@khazad-dum.debian.net

Re: default init on non-Linux platforms

2014-02-18 Thread Steven Chamberlain

Apparently sysvinit scripts must be retained anyway for a smooth
migration to jessie;  also for easy backporting of jessie packages to
wheezy, and maybe other reasons.  Non-Linux ports are likely to use
those SysV init scripts, though we might invoke them from something
other than sysvinit.

I know some maintainers would like SysV init scripts to disappear, but
the earliest I think that can happen for existing packages would be
jessie+1.  In that case, we should try to plan for a similar migration
from jessie to jessie+1.

It's difficult to predict so far ahead, but if it will be a migration to
OpenRC, maybe jessie should try to have OpenRC already in place, so that
it will be able to use jessie+1's runscripts when they appear and be
able to shut down cleanly when SysV init scripts are gone.

(I think Thomas was describing the same situation in the context of sid)

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5303f898.7070...@pyro.eu.org

Re: default init on non-Linux platforms