On Sat, Jan 18, 2014 at 08:49:48PM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
> > On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
>
> >> There is a natural process here, where rarely-used configurations
> >> slowly stop working and people eventually decide not to bother to kee
Adrian Bunk writes:
> On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
>> There is a natural process here, where rarely-used configurations
>> slowly stop working and people eventually decide not to bother to keep
>> them working and move on to other things. Eventually, they may acq
On Sat, Jan 18, 2014 at 01:20:41PM +0100, Bastian Blank wrote:
> Untested patch:
>
> - Static services with the correct name.
Well, the original names from the upstream patch weren't really incorrect.
You just have to make sure that the lvm2 sysv init script is correcly
"shadowed" by the native s
On Sat, Jan 18, 2014 at 11:22:06AM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
>...
> > We are in full agreement on that.
>
> > And my point on top of that is that if the CTTE decsion would be that
> > Debian should support multiple init systems, but it does not set a
> > policy limiting str
Adrian Bunk writes:
> On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote:
>> If software that people want to package for Debian is deeply entangled
>> in one init system (that is supported in Debian), for good or for ill,
>> regardless of what one might think of the decisions made by up
On Fri, Jan 17, 2014 at 12:51:48PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Bug#727708: Init system resolution open questions"):
> > (Only as a PM since I am repeating myself.)
>
> Thanks for your mail. I think it deserves wider consideration.
>
> > One question you should consider a
On Sat, Jan 18, 2014 at 09:45:35AM -0800, Russ Allbery wrote:
>...
> If software that people want to package for Debian is deeply entangled in
> one init system (that is supported in Debian), for good or for ill,
> regardless of what one might think of the decisions made by upstream that
> created
On Sat, 18 Jan 2014, Ian Jackson wrote:
> Do you recognise that a decision to make systemd the only supported
> init would mean the end of non-Linux-based ports of Debian ?
Which is why I'm not proposing it at this juncture. However, moving to a
single supported init system with a defined interfac
Tollef Fog Heen writes:
> I believe you can do this fairly easily.
> A is the service that needs to be reloaded when a network device shows
> up. In A's service file, have ReloadPropagatedFrom=network.target and
> then make your ifup@.service include an ExecStart=systemctl reload
> network.targ
Adrian Bunk writes:
> Why does logind actually have to be a hard dependency for GNOME in
> jessie?
If it doesn't, then it's not an issue. But it seemed like at least a
possibility given upstream GNOME direction.
> What is your general position on what dependencies on a specific init
> system a
Anthony Towns writes:
> I think this would be most analogous to the "complex conditions" bit,
> where you'd say
> start on Y and Q
> so that it will only be started when event "Q" happens if "Y" has also
> already happened. I don't see how you'd prevent it from being manually
> started withou
Hi Bastian,
Bastian Blank writes:
> On Sat, Jan 18, 2014 at 11:47:11AM +0100, Michael Stapelberg wrote:
>> --- /dev/null
>> +++ b/debian/lvm2-activation-early.service
>
> Wrong name.
Renaming them to lvm2{,-early}.service as you suggested is fine with me.
>> +[Unit]
>> +Description=Activation of
On Fri, Jan 17, 2014 at 11:29 AM, Thorsten Glaser wrote:
> Moritz Muehlenhoff dixit:
>
>>FreeBSD upstream isn't a desktop OS and never will be, there're just too
>>many deficiencies (e.g. lack of dbus
>
> Eh, excuse me! It’s obviously possible to run a desktop without dbus!
> In fact, this is a fea
Le Sat, 18 Jan 2014 10:43:30 +0100,
Laurent Bigonville a écrit :
> Hi,
After a small discussion with Bastian I realized that I was confused
with the generator and lvmetad (I should have done my homework a bit
more carefully).
> Just came here to add my 2¢ about this in the light of my recent
>
Don Armstrong writes ("Bug#727708: Thoughts on Init System Debate"):
> 3: Frankly, I don't want to support more than one set of init files; if
> the other architectures are to be release architectures, they really
> should get whatever the CTTE decides is the default init system ported
> to them, a
Untested patch:
- Static services with the correct name.
- lvm2.service is statically hooked to local-fs.target, as all local
mounts.
- lvm2-early.service is statically hooked to cryptsetup.target, as all
crypto devices.
| drwxr-xr-x root/root 0 2014-01-18 12:32 ./lib/systemd/
| drwxr
On Sat, Jan 18, 2014 at 11:47:11AM +0100, Michael Stapelberg wrote:
> --- /dev/null
> +++ b/debian/lvm2-activation-early.service
Wrong name.
> +[Unit]
> +Description=Activation of LVM2 logical volumes
> +Documentation=man:lvm(8) man:vgchange(8)
> +DefaultDependencies=no
> +After=systemd-udev-sett
Hi Don,
Don Armstrong writes:
> Michael: can you go ahead and prepare the patch to fix #728486 which
> does not use generators so that once the CTTE has resolved the init
> system question we have a patch in front of us that we can rule on?
Of course!
Attached you can find a patch against the cu
Hi,
Just came here to add my 2¢ about this in the light of my recent
experience I had with an other package (nut) where devices were not
present when the daemon was starting.
My initial solution was also to depends against udev-settle.service
service. This was ensuring that the devices were prese
On Fri, Jan 17, 2014 at 08:13:30PM -0800, Russ Allbery wrote:
>...
> I believe it is reasonable to allow GNOME to require systemd as the init
> system if that's the only way to get a working logind with the software
> that we release with jessie,
Why does logind actually have to be a hard dependen
* Russ Allbery (r...@debian.org) [140118 05:15]:
> Steve Langasek writes:
>
> > I don't believe we need to know the answer to these questions to know
> > that Ian's requirement is a correct one. If we are saying that packages
> > cannot drop their sysvinit scripts in jessie in order to ensure sm
]] Russ Allbery
> That, however, is also a good point. This specific case is the place
> where an event model does have a clear advantage. It looks like the
> preferred strategy in the systemd model is to teach daemons to watch for
> this themselves, which while certainly a good idea (most high
If notice of a systems administrator interests you:
upstart & systemd > /dev/null
Now please go look OpenRC:
http://en.wikipedia.org/wiki/OpenRC
I put the link to wikipedia :)
Lightweight, easily editable and portable. What more?
Best regards,
--
To UNSUBSCRIBE, email to debian-ctte-requ...@l
On Fri, Jan 17, 2014 at 08:41:32PM -0800, Don Armstrong wrote:
>...
> With all that said, I think all of these considerations give me a slight
> preference for systemd over upstart, though I believe that whatever the
> committee decides on will be a great improvement over venerable SysV.
>...
> 3:
24 matches
Mail list logo
