[Stefano Zacchiroli]
> If you are ready to monitor the issue closely, I don't see any
> problem in switching the default now in unstable, see how it goes,
> and then decide later on if revert back to the current default in
> Squeeze time.
The switch to parallel booting was done 2010-05-14 in unst
On Sun, 2010-05-16 at 14:18:57 +, Clint Adams wrote:
> On Sat, May 15, 2010 at 10:57:56PM +0200, Petter Reinholdtsen wrote:
> > > Was this request ever actually made to the kfreebsd porters? I'm not sure
> > > that it was, in which case it's rather unfair to say that they've had
> > > enough
On Monday 10 May 2010 09:24:59 Steve Langasek wrote:
> And you don't have to use an initramfs; the same result could be achieved
> with a shim init on the root filesystem that does nothing but set up the
> SELinux context correctly and then exec upstart.
That's what I did years ago when we first s
On Sunday 16 May 2010 03:35:09 Steve Langasek wrote:
> Given the difference in how kernels vs. init daemons are usually
> administered as part of a system, I think the runtime impact of supporting
> multiple LSMs in init is much more significant than supporting multiple
> LSMs in the kernel. I don
On Friday 14 May 2010 23:25:37 Scott James Remnant wrote:
> > Or just have per-user cgroups that a process is moved into when
> > logging in, see libpam-cgroup for something that does this.
> >
> >
>
> Then getty would respawn the second you login, stealing the controlling
> terminal from bash.
On Sun, May 09, 2010 at 13:27:08 +0200, Marc Haber wrote:
> On Sat, 8 May 2010 11:47:40 +0200, Julien Cristau
> wrote:
> >As far as I'm concerned, "faster boot" is irrelevant. Using an init
> >daemon that actually does its job of supervising services, and lets us
> >get rid of most of the stupidi
On Mon, May 17, 2010 at 03:06:10PM +0100, Scott James Remnant wrote:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543420#10
> >
> This pretty much proves my point. I was never sent these patches,
> instead Debian kept them to itself and never attempted to get them
> upstream.
Well, we ca
> > I have never rejected any SELinux patches for Upstart; I have simply
> > never been *sent* any.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543420#10
>
This pretty much proves my point. I was never sent these patches,
instead Debian kept them to itself and never attempted to get the
On Mon, May 17, 2010 at 13:04:17 (CEST), Marc Haber wrote:
> On Fri, 14 May 2010 11:30:17 +0200, Scott James Remnant
> wrote:
>>> What is so bad about init scripts? Where am I supposed to put my init
>>> script magic[1] in an upstart scenario?
>>>
>>Upstart job configs go in /etc/init
>
> And I
On Fri, 14 May 2010 11:30:17 +0200, Scott James Remnant
wrote:
>> What is so bad about init scripts? Where am I supposed to put my init
>> script magic[1] in an upstart scenario?
>>
>Upstart job configs go in /etc/init
And I can do arbitrary things there, just as with an init script?
Greetings
On 17/05/10 00:06, Petter Reinholdtsen wrote:
[Felipe Sateler]
Here I get worse results for concurrency than non-concurrent:
CONCURRENCY=none: 51s
CONCURRENCY=makefile: 59s
CONCURRENCY=none + readahead: 37s
CONCURRENCY=makefile + readahead:
[Felipe Sateler]
> Here I get worse results for concurrency than non-concurrent:
>
> CONCURRENCY=none: 51s
> CONCURRENCY=makefile: 59s
> CONCURRENCY=none + readahead: 37s
> CONCURRENCY=makefile + readahead: 43s
This is not the way it should be, and
On 09/05/10 11:54, Eduard Bloch wrote:
#include
* Cesare Leonardi [Sun, May 09 2010, 12:26:36PM]:
Here what i've measured, from the Grub start to the Gdm prompt, in
either case starting from a completely power off machine:
Without concurrency: 33 sec.
With concurrency (try 1): 29 sec.
With conc
On Sat, May 15, 2010 at 10:57:56PM +0200, Petter Reinholdtsen wrote:
> > Was this request ever actually made to the kfreebsd porters? I'm not sure
> > that it was, in which case it's rather unfair to say that they've had enough
> > time when they were never informed this was a pressing issue.
>
>
On Fri, May 14 2010, Scott James Remnant wrote:
>> One of my concerns about upstart is that systems that want to
>> use SELinux and upstart _have_ to also use an initramfs, which is yet
>> another component of the system that has to be audited. There have
>> been patches proposed, and semi-reject
[Steve Langasek]
> Was this request ever actually made to the kfreebsd porters? I'm not sure
> that it was, in which case it's rather unfair to say that they've had enough
> time when they were never informed this was a pressing issue.
One request was done last summer, see
http://lists.debian.or
On Sun, May 09, 2010 at 06:09:10PM -0700, Manoj Srivastava wrote:
> > In speaking with upstart upstream, I understand that the argument against
> > linking to libselinux is that, as the kernel is neutral wrt the choice of
> > LSM, the init process should be also. Linking it against libselinux woul
On Sun, May 09, 2010 at 03:10:15AM +0200, Marco d'Itri wrote:
> On May 07, Julien Cristau wrote:
> > > - a decision to drop kfreebsd as a release architecture
> > Since 1 and 2 aren't happening, I think we should consider going with
> > the third option.
> Me too, I believe that the people inter
On Wed, May 12, 2010 at 09:59:59PM +0200, Petter Reinholdtsen wrote:
>
> [Cesare Leonardi]
> > If that helps, reading this thread i've set the previous variable in
> > my notebook (Sid with Gnome environment). I can see no problem but the
> > speed improvement is really small.
>
> Great to see mo
> Or just have per-user cgroups that a process is moved into when
> logging in, see libpam-cgroup for something that does this.
>
Then getty would respawn the second you login, stealing the controlling
terminal from bash.
> In addition, killing all members in a cgroup when a service goes down is
]] Scott James Remnant
| I investigated using cgroups in Upstart a while back, and hit the exact
| same issue. There are two obvious solutions:
|
| - allow a process to escape its cgroup (kernel patch); this is
|completely insane, since cgroups are primarily used for security
|containe
> It is still on the wishlist, but the needed pieces are not ready, so
> it seem unlikely to happen this late in the release process. At the
> moment, I believe it will happen shortly after Squeeze is released, if
> the needed pieces are ready by then.
>
I will be at DebConf all week.
I'll be th
> What is so bad about init scripts? Where am I supposed to put my init
> script magic[1] in an upstart scenario?
>
Upstart job configs go in /etc/init
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a d
> This does mean that when you use something like screen, the tty it was
> connected to is from then on unusable, right? As the cgroup that
> contains the screen process also contains the getty and it doesn't
> kill one without the other as that is in no way reliable :-)
>
Yes.
I investigated usi
> One of my concerns about upstart is that systems that want to
> use SELinux and upstart _have_ to also use an initramfs, which is yet
> another component of the system that has to be audited. There have
> been patches proposed, and semi-rejected b the upstart folks, who are
> of the opinions tha
On 7 May 2010 10:33, Paul Wise wrote:
> On Fri, May 7, 2010 at 4:22 PM, Goswin von Brederlow
> wrote:
>> Stefano Zacchiroli writes:
>>> The init.d world has changed quite a bit in recent years and might
>>> change even more in the next, it is possible that for Squeeze+1 we'll
>>> want to be els
[Cesare Leonardi]
> If that helps, reading this thread i've set the previous variable in
> my notebook (Sid with Gnome environment). I can see no problem but the
> speed improvement is really small.
Great to see more test results. :)
> Here what i've measured, from the Grub start to the Gdm prom
On 05/11/2010 01:09 PM, Julian Andres Klode wrote:
On Tue, May 11, 2010 at 12:49:46PM +0200, Julien Cristau wrote:
On Tue, May 11, 2010 at 12:37:56 +0200, Julian Andres Klode wrote:
On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote:
Is it really a good idea to have init depend
]] Julian Andres Klode
| On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote:
| > I am so far just testing on a singe machine, but it's my firm belief
| > that it's possible to have a fully functional systemd in squeeze.
|
| Only if #579755 is solved. While testing systemd on Debian,
On Tue, May 11, 2010 at 12:49:46PM +0200, Julien Cristau wrote:
> On Tue, May 11, 2010 at 12:37:56 +0200, Julian Andres Klode wrote:
>
> > On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote:
> > > I am so far just testing on a singe machine, but it's my firm belief
> > > that it's pos
On Tue, May 11, 2010 at 12:37:56 +0200, Julian Andres Klode wrote:
> On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote:
> > I am so far just testing on a singe machine, but it's my firm belief
> > that it's possible to have a fully functional systemd in squeeze.
>
> Only if #579755
On Sun, May 09, 2010 at 05:25:16PM +0200, Tollef Fog Heen wrote:
> I am so far just testing on a singe machine, but it's my firm belief
> that it's possible to have a fully functional systemd in squeeze.
Only if #579755 is solved. While testing systemd on Debian, I found
out that the option CONFIG
On 10/05/2010 19:45, Raphael Geissert wrote:
> Marc Haber wrote:
>> I would like to ask the maintainer to first do his job _before_
>> forcing the new mechanism on all new users. If it isn't documented, it
>> ain't fit for Debian stable, especially as a default.
>>
>
> /usr/share/doc/insserv/READM
Hi,
Eduard Bloch wrote:
> First, it was readahead-fedora. Second, I followed that README now and
> updated readahead collection. Now they take both about 29 seconds, so I
> don't win anything with readahead.
That's definitely a bug, please file it (don't forget to include a bootchart
of both cas
#include
* Raphael Geissert [Sun, May 09 2010, 01:19:31PM]:
> Eduard Bloch wrote:
> > with concurency: 30s
> > with concurency and without readahead: 28s
>
> Interesting, a regression. Is that readahead from readahead-fedora?
>
> Were the 30 seconds measured by following the instructions from
>
Marc Haber wrote:
> I would like to ask the maintainer to first do his job _before_
> forcing the new mechanism on all new users. If it isn't documented, it
> ain't fit for Debian stable, especially as a default.
>
/usr/share/doc/insserv/README.Debian
...
--
Raphael Geissert - Debian Developer
On Mon, May 10, 2010 at 03:54:19PM +0200, Marc Haber wrote:
> >Thanks for the pointer. I've just submitted a patch for #576788 that
> >adds a pointer to that file from /etc/init.d/README.
>
> I would expect this in the defaults/rcS file as well, which is the
> place where I'd look.
Agreed, and wh
On Mon, 10 May 2010 13:02:51 +0200, Stefano Zacchiroli
wrote:
>On Sun, May 09, 2010 at 04:10:58PM +0300, Eugene V. Lyubimkin wrote:
>> >According to <4be43663.6000...@free.fr> and #576788, it is not.
>> >But I'm sure Petter welcome patches on this.
>> FWIW, it appears to be documented in README.De
On Sun, 9 May 2010 14:58:51 +0200, Stefano Zacchiroli
wrote:
>On Sun, May 09, 2010 at 01:24:49PM +0200, Marc Haber wrote:
>> > CONCURRENCY=makefile
>> Where is this documented?
>
>According to <4be43663.6000...@free.fr> and #576788, it is not.
>But I'm sure Petter welcome patches on this.
I woul
On Sun, May 09, 2010 at 04:10:58PM +0300, Eugene V. Lyubimkin wrote:
> >According to <4be43663.6000...@free.fr> and #576788, it is not.
> >But I'm sure Petter welcome patches on this.
> FWIW, it appears to be documented in README.Debian in the insserv package.
Thanks for the pointer. I've just sub
On Sun, May 09 2010, Steve Langasek wrote:
> On Sun, May 09, 2010 at 02:45:39PM -0700, Manoj Srivastava wrote:
>> One of my concerns about upstart is that systems that want to
>> use SELinux and upstart _have_ to also use an initramfs, which is yet
>> another component of the system that
On Sun, May 09, 2010 at 02:45:39PM -0700, Manoj Srivastava wrote:
> One of my concerns about upstart is that systems that want to
> use SELinux and upstart _have_ to also use an initramfs, which is yet
> another component of the system that has to be audited. There have
> been patches p
On Sat, May 08 2010, Marco d'Itri wrote:
> On May 07, Julien Cristau wrote:
>
>> > - a decision to drop kfreebsd as a release architecture
>> Since 1 and 2 aren't happening, I think we should consider going with
>> the third option.
> Me too, I believe that the people interested in kfreebsd-* ha
Eduard Bloch wrote:
> with concurency: 30s
> with concurency and without readahead: 28s
Interesting, a regression. Is that readahead from readahead-fedora?
Were the 30 seconds measured by following the instructions from
/usr/share/doc/readahead-fedora/README.bootchart ?
Cheers,
--
Raphael Geiss
#include
* Cesare Leonardi [Sun, May 09 2010, 12:26:36PM]:
> Here what i've measured, from the Grub start to the Gdm prompt, in
> either case starting from a completely power off machine:
> Without concurrency: 33 sec.
> With concurrency (try 1): 29 sec.
> With concurrency (try 2): 31 sec.
Sim
]] Stefano Zacchiroli
| I've just read a few days ago the design document of systemd; AFAIU it
| requires anyhow patching various daemons, no matter how trivial the
| patches are.
No, it doesn't require it, but it allows it. Cutting and pasting from
Lennart's blog post:
An ideal daemon for u
On Sun, May 09, 2010 at 10:01:09AM +0200, Stefano Zacchiroli wrote:
> On Sat, May 08, 2010 at 07:07:44PM +0200, Petter Reinholdtsen wrote:
> > Perhaps you are right. Perhaps we should do a poll to collect
> > information on how testers experience their boot with
> > CONCURRENCY=makefile, to make i
Stefano Zacchiroli wrote:
On Sun, May 09, 2010 at 01:24:49PM +0200, Marc Haber wrote:
CONCURRENCY=makefile
Where is this documented?
According to <4be43663.6000...@free.fr> and #576788, it is not.
But I'm sure Petter welcome patches on this.
FWIW, it appears to be documented in README.Deb
On Sun, May 09, 2010 at 01:24:49PM +0200, Marc Haber wrote:
> > CONCURRENCY=makefile
> Where is this documented?
According to <4be43663.6000...@free.fr> and #576788, it is not.
But I'm sure Petter welcome patches on this.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Un
[Stefano Zacchiroli]
> If you are ready to monitor the issue closely, I don't see any problem
> in switching the default now in unstable, see how it goes, and then
> decide later on if revert back to the current default in Squeeze
> time. Ideally, you should probably communicate a on the matter whe
On Sat, 8 May 2010 11:47:40 +0200, Julien Cristau
wrote:
>As far as I'm concerned, "faster boot" is irrelevant. Using an init
>daemon that actually does its job of supervising services, and lets us
>get rid of most of the stupidity and boilerplate of init scripts, otoh,
>is overdue.
What is so b
On Sat, 8 May 2010 11:51:22 +0200, Stefano Zacchiroli
wrote:
>On Sat, May 08, 2010 at 11:37:10AM +0200, Marc Haber wrote:
>> So it is the classical desktop vs. server situation. For my Debian
>> servers, that get booted at most once a month, I don't give a damn
>> about a faster boot.
>>
>> I _do
On Thu, 06 May 2010 21:11:56 +0200, Petter Reinholdtsen
wrote:
>These days, the init.d script dependencies in Squeeze are quite
>complete, so complete that it is actually possible to run all the
>init.d scripts in parallell based on these dependencies. If you want
>to test your Squeeze system, ma
On May 09, Stefano Zacchiroli wrote:
> I've just read a few days ago the design document of systemd; AFAIU it
> requires anyhow patching various daemons, no matter how trivial the
> patches are.
Patching the daemons is needed if you want it to open the listening
sockets for them. If you do not, i
On 08/05/2010 19:07, Petter Reinholdtsen wrote:
Perhaps we should do a poll to collect
information on how testers experience their boot with
CONCURRENCY=makefile, to make it easier to switch with some confidence
that it would work for most users. :)
If that helps, reading this thread i've set t
On 8 May 2010 19:07, Petter Reinholdtsen wrote:
> Perhaps you are right. Perhaps we should do a poll to collect
> information on how testers experience their boot with
> CONCURRENCY=makefile, to make it easier to switch with some confidence
> that it would work for most users. :)
It just came t
On Sun, May 09, 2010 at 08:06:12AM +0200, Tollef Fog Heen wrote:
> I just filed an ITP on systemd and am planning on
Amazing!, thanks for this.
> making it installable alongside with sysvinit, switchable with
> init=/sbin/systemd when booting. Eventually, I guess either using
> alternatives for
On Sat, May 08, 2010 at 07:07:44PM +0200, Petter Reinholdtsen wrote:
> Perhaps you are right. Perhaps we should do a poll to collect
> information on how testers experience their boot with
> CONCURRENCY=makefile, to make it easier to switch with some confidence
> that it would work for most users.
]] (Marco d'Itri)
| Removing the Essential flag from sysvinit would allow interested admins
| to install upstart on their systems if they want to benefit from its
| features. I am not sure how much useful it would be to also switch to
| upstart by default in this scenario, I welcome other opinion
On May 07, Julien Cristau wrote:
> > - a decision to drop kfreebsd as a release architecture
> Since 1 and 2 aren't happening, I think we should consider going with
> the third option.
Me too, I believe that the people interested in kfreebsd-* have had more
than enough time to provide the compat
[Kai Wasserbäch]
> as one of the testers just a short reply: on several desktops and
> some basic servers insserv in conjunction with
> "CONCURRENCY=makefile" works well. I didn't have an unbootable
> system so far.
Thank you. Note that I do not expect an unbootable system. The worst
I expect a
Hello Petter,
Petter Reinholdtsen schrieb am 08.05.2010 19:07:
> Perhaps we should do a poll to collect
> information on how testers experience their boot with
> CONCURRENCY=makefile, [...]
as one of the testers just a short reply: on several desktops and some basic
servers insserv in conjunction
[Stefano Zacchiroli]
> Fair enough. IMO you've done quite a lot of communication on the matter
> (at least to us developers) and I've personally been testing
> CONCURRENCY=makefile in response to your repeated call for testers. At
> this point, I doubt you can get significantly more testers without
On 05/08/2010 11:47 AM, Julien Cristau wrote:
On Fri, May 7, 2010 at 19:27:54 +0200, Stefano Zacchiroli wrote:
(Beside the nitpick on "we want" vs "we possibly want") I'd argue that
it's because we want a faster boot from our users ASAP.
As far as I'm concerned, "faster boot" is irrelevant.
On 05/07/2010 09:59 AM, Mike Hommey wrote:
> On Fri, May 07, 2010 at 09:47:36AM +0200, Josselin Mouette wrote:
>> Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
>>> These days, the init.d script dependencies in Squeeze are quite
>>> complete, so complete that it is actually possi
On Fri, May 07, 2010 at 10:06:52AM +0200, Petter Reinholdtsen wrote:
> All of this is based on my belief that there are very few people
> testing with CONCURRENCY=makefile. If a lot of people are using it
> successfully, it is less likely that there are many race conditions
> and edge cases left t
On Sat, May 08, 2010 at 11:37:10AM +0200, Marc Haber wrote:
> So it is the classical desktop vs. server situation. For my Debian
> servers, that get booted at most once a month, I don't give a damn
> about a faster boot.
>
> I _do_ care, however, about not having migrations in the boot process
> w
On Fri, May 7, 2010 at 19:27:54 +0200, Stefano Zacchiroli wrote:
> (Beside the nitpick on "we want" vs "we possibly want") I'd argue that
> it's because we want a faster boot from our users ASAP.
>
As far as I'm concerned, "faster boot" is irrelevant. Using an init
daemon that actually does its
On Fri, 7 May 2010 19:27:54 +0200, Stefano Zacchiroli
wrote:
>On Fri, May 07, 2010 at 06:15:24PM +0200, Marc Haber wrote:
>> On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli
>> wrote:
>> >The init.d world has changed quite a bit in recent years and might
>> >change even more in the next, it
Vincent Danjean wrote:
> Having a compat layer would also allow
> to stick to sysvinit on linux ports. I think this is very important
> because *lots* of system uses local sysvinit scripts and does not have
> ported them to upstart (not even to inserv dependency...)
Support for SysV init scripts
On Fri, May 07, 2010 at 06:15:24PM +0200, Marc Haber wrote:
> On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli wrote:
> >The init.d world has changed quite a bit in recent years and might
> >change even more in the next, it is possible that for Squeeze+1 we'll
> >want to be elsewhere than at
On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli
wrote:
>The init.d world has changed quite a bit in recent years and might
>change even more in the next, it is possible that for Squeeze+1 we'll
>want to be elsewhere than at CONCURRENCY=makefile.
If we want to be elsewhere for squeeze+1, why
Since -bsd@ might be interested, Cc-ing them:
Steve Langasek (07/05/2010):
> On Fri, May 07, 2010 at 03:15:25PM +0200, Julien Cristau wrote:
> > On Fri, May 7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:
>
> > > [Aaron Toponce]
> > > > I thought Upstart was on the list for release in Sqe
On 07/05/2010 16:24, Julien Cristau wrote:
> On Fri, May 7, 2010 at 15:47:39 +0200, Steve Langasek wrote:
>
>> Upstart doesn't work on any kernels other than Linux. The original goal was
>> to have a compat layer to pull upstart jobs into the sysvinit system, which
>> would both address the hurd
On Fri, May 7, 2010 at 15:47:39 +0200, Steve Langasek wrote:
> Upstart doesn't work on any kernels other than Linux. The original goal was
> to have a compat layer to pull upstart jobs into the sysvinit system, which
> would both address the hurd/BSD kernel issues and allow a soft transition to
On Fri, May 07, 2010 at 03:15:25PM +0200, Julien Cristau wrote:
> On Fri, May 7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:
> > [Aaron Toponce]
> > > I thought Upstart was on the list for release in Sqeeze. Has this changed?
> > > http://lists.debian.org/debian-devel-announce/2009/09/msg
[Julien Cristau]
> What are the "needed pieces"?
I am sorry, do not have time to write a full update, so I give a quick
pointer instead. The list we use to discuss the boot system work is
initscripts-ng-de...@. See for example
http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/2010-Ma
On Fri, May 7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:
>
> [Aaron Toponce]
> > I thought Upstart was on the list for release in Sqeeze. Has this changed?
> >
> > http://lists.debian.org/debian-devel-announce/2009/09/msg3.html
>
> It is still on the wishlist, but the needed pieces
[Aaron Toponce]
> I thought Upstart was on the list for release in Sqeeze. Has this changed?
>
> http://lists.debian.org/debian-devel-announce/2009/09/msg3.html
It is still on the wishlist, but the needed pieces are not ready, so
it seem unlikely to happen this late in the release process. A
On 5/7/2010 2:33 AM, Paul Wise wrote:
> Other distros are using upstart:
>
> http://upstart.ubuntu.com/
I thought Upstart was on the list for release in Sqeeze. Has this changed?
http://lists.debian.org/debian-devel-announce/2009/09/msg3.html
--
. O . O . O . . O O . . . O .
. . O
On May 07, Mike Hommey wrote:
> And kernel+initramfs. That's more than half the boot time (without
> even CONCURRENCY=makefile) here.
I am still waiting for an answer from the kernel/initramfs-tools
maintainer about moving udevsettle from init-top to premount.
--
ciao,
Marco
signature.asc
Des
On Fri, May 07, 2010 at 10:22:14AM +0200, Goswin von Brederlow wrote:
> Did you actualy read the mail till the end?
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-de...@lists.alioth.debian.org
Yes, I did, and I noticed that none of those bugs are RC severity,
that's why I've e
On Fri, May 7, 2010 at 4:22 PM, Goswin von Brederlow wrote:
> Stefano Zacchiroli writes:
>> The init.d world has changed quite a bit in recent years and might
>> change even more in the next, it is possible that for Squeeze+1 we'll
>> want to be elsewhere than at CONCURRENCY=makefile.
>
> Yet aga
Stefano Zacchiroli writes:
> On Thu, May 06, 2010 at 09:11:56PM +0200, Petter Reinholdtsen wrote:
>> These days, the init.d script dependencies in Squeeze are quite
>> complete, so complete that it is actually possible to run all the
>> init.d scripts in parallell based on these dependencies.
>
On Fri, May 7, 2010 at 2:59 PM, Mike Hommey wrote:
> On Fri, May 07, 2010 at 09:47:36AM +0200, Josselin Mouette wrote:
>> Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
>> > These days, the init.d script dependencies in Squeeze are quite
>> > complete, so complete that it is act
[Stefano Zacchiroli]
> From your message I can't exactly tell why we can't have it for
> Squeeze. My personal experience is that I've been using
> CONCURRENCY=makefile since several months now, and I've never run
> into problems.
I know there are bugs in the dependencies, which only affect some
c
On Fri, May 07, 2010 at 09:47:36AM +0200, Josselin Mouette wrote:
> Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
> > These days, the init.d script dependencies in Squeeze are quite
> > complete, so complete that it is actually possible to run all the
> > init.d scripts in paral
Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
> These days, the init.d script dependencies in Squeeze are quite
> complete, so complete that it is actually possible to run all the
> init.d scripts in parallell based on these dependencies. If you want
> to test your Squeeze syst
On Thu, May 06, 2010 at 09:11:56PM +0200, Petter Reinholdtsen wrote:
> These days, the init.d script dependencies in Squeeze are quite
> complete, so complete that it is actually possible to run all the
> init.d scripts in parallell based on these dependencies.
> Running scripts in parallel could
These days, the init.d script dependencies in Squeeze are quite
complete, so complete that it is actually possible to run all the
init.d scripts in parallell based on these dependencies. If you want
to test your Squeeze system, make sure dependency based boot
sequencing is enabled, and add this l
90 matches
Mail list logo
