Re: [DNG] [Dng] vdev status update: device properties and udev compatibility

2015-06-25 Thread Daniel Reurich
On 25/06/15 17:04, Jude Nelson wrote: Hey everyone, After a longer-than-expected development cycle, I have the latest news for vdev. The TL;DR is that vdev has gained enough infrastructure to generate the information that normally gets put in /run/udev. This is important for most libudev

Re: [DNG] [Dng] vdev status update: device properties and udev compatibility

2015-06-25 Thread KatolaZ
On Thu, Jun 25, 2015 at 01:04:24AM -0400, Jude Nelson wrote: Hey everyone, After a longer-than-expected development cycle, I have the latest news for vdev. The TL;DR is that vdev has gained enough infrastructure to generate the information that normally gets put in /run/udev. This is

Re: [DNG] Packages aren't the only path to alternate inits

2015-06-25 Thread Mat
On 18/06/15 13:47, Didier Kryn wrote: [...] I wonder if now is the time to start separating out the init specific configuration files, initscripts or service files, libraries and binaries out into separate packages so that any particular init can be supported without treading on the toes of

[DNG] accessibility in devuan

2015-06-25 Thread Gregory Nowak
Hello everyone, I've been lurking on this list for a couple of weeks, and this is my first post here. I'd like to start by saying a big thank you to those working hard to bring us debian jessie and beyond without systemd. I like to keep an open mind, so after reading arguments for and against

Re: [DNG] accessibility in devuan

2015-06-25 Thread Daniel Reurich
Hi Greg, Thanks for the bug report. Yes this is a very net-install mini iso (I think debian refered to it previously as the business card iso) which has only just enough bits to get on the net to download the resot of the installer. We don't yet produce the fuller iso matching debian's

Re: [DNG] Packages aren't the only path to alternate inits

2015-06-25 Thread Florian
On Thu, 18 Jun 2015 16:58:59 +0200 Mat m...@parad0x.org wrote: So in general I think that this approach - moving init system specific things out of the main package and providing one package per init system - is a good way of supporting multiple init systems. For instance: