headers
Adam Borowski | 1 Jan 01:13
Picon
Favicon
Gravatar

Re: Parallel build results

On Mon, Dec 31, 2007 at 10:07:15PM +0100, Robert Millan wrote:
> On Sat, Dec 01, 2007 at 09:21:33PM -0500, Daniel Schepler wrote:
> > I finally got through the test builds of all the source packages in sid for 
> > i386 using dpkg-buildpackage -j3 on a dual core machine.  The results as 
> > before are at http://people.debian.org/~schepler/build-logs/bymaint.html .  
> 
> Why -j3 ?  It's already quite an effort to aim for -j2.  Shouldn't we try to
> fix those first?

Once you go over -j1, nearly all usual race conditions can be potentially
triggered.  You would need a quite contrived build system to get a three-way
race which cannot fail with -j2.

And races caused by doing more than one task at once are pretty rare, in
most in the cases the failure is due to wrong dependences.  The root of the
problem is, people are used to a single-tasked make which always builds
everything from left to right.  Things won't break until -j or -k is used.

What about changing make so it builds prerequisites in a random order, or at
least right-to-left which is typically the worst case?  This would help spot
dependency problems other than true races.

(an example which will not be caught by hypothethical make --order=random
but will likely break for -j higher than 1:

all: foo bar

foo: foo.c
	gcc src.c
	mv a.out $(target)/foo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aníbal Monsalve Salazar | 1 Jan 05:47
Picon
Favicon

Bug#458497: ITP: pacemaker -- scalable High-Availability cluster resource manager

Package: wnpp
Severity: wishlist
Owner: anibal <at> debian.org

* Package name    : pacemaker
  Version         : 0.6.0
  Upstream Author : Andrew Beekhof <abeekhof <at> suse.de>
* URL             : http://www.clusterlabs.org/
* License         : GPL2/LGPL2
  Programming Lang: C
  Description     : scalable High-Availability cluster resource manager

Pacemaker is an advanced, scalable High-Availability cluster
resource manager for Linux-HA (Heartbeat) and/or OpenAIS.

It supports "n-node" clusters with significant capabilities for
managing resources and dependencies.

It will run scripts at initialization, when machines go up or down,
when related resources fail and can be configured to periodically
check resource health.
Permalink | Reply | 0 comments |
headers
Andreas Metzler | 1 Jan 11:27
X-Face

Re: Producing multiple -dbg packages using CDBS

Nicolas CANIART <nicolas.caniart <at> labri.fr> wrote:
>  I would like to know if someone could point me out the way one can
> produce more than one -dbg package using CDBS ? (a package doing that
> or some doc)
>  The changelog says it is possible as of version 0.4.38, but does not
> provides any hints on how.

[...]
/usr/share/doc/cdbs/cdbs-doc.html
To control more finely which debug symbols go where, in particular if you want
to build more than one debug package, there are variables
DEB_DBG_PACKAGE_package that specify the debug package target for each
individual binary package. An example usage would be:

DEB_DBG_PACKAGE_libfoo4 = libfoo-dbg
DEB_DBG_PACKAGE_foo-bin = foo-bin-dbg
[...]

cu andreas
--

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Permalink | Reply | 1 comment |
headers
Florian Weimer | 1 Jan 14:47
Picon

Re: Editing the sources in "debian/rules clean"

* Miriam Ruiz:

> 2007/12/26, Florian Weimer <fw <at> deneb.enyo.de>:
>> This the issue, but I think it could be more widespread.  It turns out
>> that the package in question (tar) was last uploaded before the
>> autotools were finalized for etch, so the copying is not a no-op in this
>> particular case (but I hope that the update does not introduce
>> functional changes).
>
> Well, it seems quite widespread to copy autotools config.sub and
> config.guess files from autotools-dev in clean (I personally prefer to
> do that in configure, and to remove config.{sub,guess,log,status} in
> clean, so that diff files are cleaner, but I guess that might be
> personal taste), are you referring to that, or to something else?

Okay, okay.  It's probably a good idea.  I'm going to file a bug on
Policy.  I've no idea what the language addressing this should look
like, but I think we really should bring Policy closer to existing
practice (and not the other way round, as I first thought).
Permalink | Reply | 0 comments |
headers
Petter Reinholdtsen | 1 Jan 15:24
Gravatar

Faster shutdown and the ubuntu "multiuser" update-rc.d extention


Did you ever curse that Debian took so long to shut down, waiting for
all the shutdown scripts to complete before the machine was ready to
move?  Here is a simple recipe to help making sure your package do not
slow down the shutdown.

Most of the init.d scripts are simple scripts that during shutdown
kill the process they started during boot.  But the default halt (0)
and reboot (6) shutdown sequences will kill all processes on their own
(in the sendsigs script), so there is normally no need for individual
packages and init.d scripts to run at shutdown if all they need to do
is to kill a daemon.  There might be exceptions, for example if the
daemons need to stop in a given order, but that do not seem to be the
case for most packages.

Ubuntu discovered this a while back, and introduced a method to avoid
calling stop scripts in runlevel 0 and 6.  It is the "multiuser"
extension to update-rc.d, and in Ubuntu packages are changed to calls
dh_installinit with '-- multiuser' as an argument to enable it.  This
add the "multiuser" argument (instead of to the "default" argument) to
update-rc.d, which go on and set up the boot sequence without
references to the script in runlevel 0 and 6.  This can be done
without such extention, and how is the topic of the rest of my email.

To change the runlevel settings of an init.d script using the Debian
API, one most first remove it in the postinst, and insert it again.
To do this, add code like this in the postinst before the #DEBHELPER#
block:

  if dpkg --compare-versions "$2" lt "0.1"; then
(Continue reading)

Permalink | Reply | 68 comments |
headers
Andreas Metzler | 1 Jan 16:01
X-Face

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Petter Reinholdtsen <pere <at> hungry.com> wrote:
[...]
> To change the runlevel settings of an init.d script using the Debian
> API, one most first remove it in the postinst, and insert it again.
> To do this, add code like this in the postinst before the #DEBHELPER#
> block:

>  if dpkg --compare-versions "$2" lt "0.1"; then
>      update-rc.d -f hotkey-setup remove
>  fi
[...]

Is this acceptable according to policy? This will simply discard all
local customzations like disabling he service in a special runlevel.
cu andreas
--

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Permalink | Reply | 7 comments |
headers
Petter Reinholdtsen | 1 Jan 17:28
Gravatar

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention


[Andreas Metzler]
> Is this acceptable according to policy? This will simply discard all
> local customzations like disabling he service in a special runlevel.

As far as I know, this is the official and supported way.  There is no
'move' option in the update-rc.d API, so I am not aware of any other
way to do it.

Happy hacking,
--

-- 
Petter Reinholdtsen
Permalink | Reply | 6 comments |
headers
Joey Hess | 1 Jan 20:24
Picon
Favicon
Gravatar

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Petter Reinholdtsen wrote:
> Ubuntu discovered this a while back, and introduced a method to avoid
> calling stop scripts in runlevel 0 and 6.  It is the "multiuser"
> extension to update-rc.d

Why is this extension not available in our update-rc.d? As a bonus it
could stop at sequence number 80 too so we could transition to a better
order for runlevel 1.

> And while you work on your init.d scripts, please make sure to update
> the LSB-style header Should-Stop to reflect that the script do not
> need to stop in runlevels 0 and 6.  See
> <URL: http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot > for
> more info on this feature.

I don't see documentation about Should-Stop there.

--

-- 
see shy jo
Permalink | Reply | 21 comments |
headers
Joey Hess | 1 Jan 20:29
Picon
Favicon
Gravatar

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Petter Reinholdtsen wrote:
> 
> [Andreas Metzler]
> > Is this acceptable according to policy? This will simply discard all
> > local customzations like disabling he service in a special runlevel.
> 
> As far as I know, this is the official and supported way.  There is no
> 'move' option in the update-rc.d API, so I am not aware of any other
> way to do it.

I was also worried about this when reading your mail. There's no better
way to do it, but is the data loss small enough that it's not a bug if a
package does it? I know a lot of people re-order xdm to run earlier in
boot. If I were the xdm maintainer, I'd fear the storm of bugs if I did
this and lost their settings[1].

The alternative would be changing the default for new installs, but leaving
existing installs as-is.

--

-- 
see shy jo

[1] Really it probably makes sense to explicitly stop xdm during shutdown
    anyway, since that more cleanly shuts down X.
Permalink | Reply | 3 comments |
headers
Russ Allbery | 1 Jan 20:45
Picon
Favicon

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Petter Reinholdtsen <pere <at> hungry.com> writes:
> [Andreas Metzler]

>> Is this acceptable according to policy? This will simply discard all
>> local customzations like disabling he service in a special runlevel.

> As far as I know, this is the official and supported way.  There is no
> 'move' option in the update-rc.d API, so I am not aware of any other
> way to do it.

Shouldn't we add a move option to update-rc.d first rather than telling
people to do this?  It seems like a generally useful thing to have, and I
don't like the idea of throwing away people's init script order
customizations.

--

-- 
Russ Allbery (rra <at> debian.org)               <http://www.eyrie.org/~eagle/>
Permalink | Reply | 1 comment |

Gmane