www.perdidacabello.com.ar

[Pls check this new site]

Please see this site in Subject

www.diavetes.com.ar

[Pls check this new site]

Please see this site in Subject

Re: Producing multiple -dbg packages using CDBS

[Andreas Metzler]

Nicolas CANIART <[EMAIL PROTECTED]> 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'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Florian Weimer]

* Miriam Ruiz:

> 2007/12/26, Florian Weimer <[EMAIL PROTECTED]>:
>> 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).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Petter Reinholdtsen]

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
  update-rc.d -f hotkey-setup remove
  fi

The version number used when comparing should be the version of the
package where the change is introduced.

Next, change the dh_installinit call in debian/rules file to look like
this (note, not the optimal solution):

  dh_installinit -- start 20 2 3 4 5 . stop 20 1 .

This is equivalent to the 'dh_installinit -- multiuser' call on
Ubuntu, and will make debhelper add code to call update-rc.d with the
given arguments.

It is a long-standing Bug in the Debian single user and shutdown
sequence that the services are not stopped in the opposite order of
the one used when starting them.  The default setting is to start at
sequence number 20, and stop also using sequence number 20.  A better
default would have been to use a stop sequence number that is 100
minus the start sequence number, but it is too late to change the
behavior of update-rc.d.  Each package maintainer can on the other
hand fix his package like this:

  dh_installinit -- start 20 2 3 4 5 . stop 80 1 .

Of course, one need to verify that the stop script will still work
when stopped at sequence number 80 in the single user runlevel, before
introducing such change.

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
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot > for
more info on this feature.

Happy hacking,
-- 
Petter Reinholdtsen
One of the sysvinit maintainers


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bonne Année 2008

[PSI Informatique éditeur logiciel de gestion]

 
  Si vous ne visualisez pas correctement cet e-mail, cliquez ici  
 

 
 


Nous vous prions de nous excuser si cette lettre d'information vous   a 
causé un quelconque désagrément.

Pour ne plus recevoir d'emailing de PSI informatique  cliquez ici 

Pour inscrire un ami cliquez ici
  


 

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

[Andreas Metzler]

Petter Reinholdtsen <[EMAIL PROTECTED]> 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'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Petter Reinholdtsen]

[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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Joey Hess]

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
> http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot > for
> more info on this feature.

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

-- 
see shy jo


signature.asc
Description: Digital signature

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

[Joey Hess]

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.


signature.asc
Description: Digital signature

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

[Russ Allbery]

Petter Reinholdtsen <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#140230: styx nullstellensatz

[Karyn Cobbm]

Greetings,
wouldn't you wont big cock
http://www.rapkocrats.com

Demetrius




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Producing multiple -dbg packages using CDBS

[Nicolas CANIART]

On Tue, Jan 01, 2008 at 11:27:10AM +0100, Andreas Metzler wrote:
> Nicolas CANIART <[EMAIL PROTECTED]> 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'
> 
> 

All right, I should try to avoid thinking the docs available on the
net are more accurate than the one installed on my computer (thanks to
DDs hard work); shame on me.

My apologies for wasting your time and thank you for the answer.
It worked like a charm, of course.

-- 
Nicolas CANIART  | PhD. Student
LaBRI, Domaine Universitaire | Room :  378
351, Cours de la Libération  | Phone : +33 (0)540 003 511
F-33405 Talence CEDEX| e-mail: [EMAIL PROTECTED]


signature.asc
Description: Digital signature

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

[Petter Reinholdtsen]

[Russ Allbery]
> 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.

Well, I am not quite sure how it should work, but would welcome a way
to modify the default settings while keeping the changes done by the
sysadmin, if we can get sane semantics for it.

I am not going to work on it myself any time soon, as I
focus on the dependency based boot sequencing,
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot >.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Petter Reinholdtsen]

[Joey Hess]
> The alternative would be changing the default for new installs, but leaving
> existing installs as-is.

Yes.  That might be an acceptable alternative.

> [1] Really it probably makes sense to explicitly stop xdm during shutdown
> anyway, since that more cleanly shuts down X.

How does it more cleanly shut down X?  That seem to be the logic
behind providing all the stop scripts in runlevel 0 and 6, just to
kill a process.  There is nothing magic about sending a signal. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Petter Reinholdtsen]

[Joey Hess]
> 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.

I have not invested much time to implement that extension, as it would
have to be first specified in the update-rc.d API, then implemented by
sysv-rc and file-rc.  As I said, it is possible to get the same
behavior by replacing 'default' with something else, so I am not sure
if it is better to insert 'multiuser' instead of 'start 20 2 3 4 5
. stop 20 1 .'.  It is definitely easier and shorter, but as I said it
is also not quite optimal using 20 as the stop sequence, so I am not
sure it is a feature to copy into Debian.

I've instead spent my time working on the dependency based boot
sequencing system, because I believe it solve this and other problems
in a more elegant way.  It allow us to specify per script where in the
boot and shutdown sequence it should run, and which runlevel it should
run in.  It is now working fairly well, as documented on 
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot >.

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

Right.  Sorry.  See the parent page, 
http://wiki.debian.org/LSBInitScripts >.  And I ment to say
Default-Stop, not Should-stop.

What about changing the default values for dh_installinit for a future
debhelper compatibility layer, to use 'start 20 2 3 4 5 . stop 80 1 .'
instead of 'default' when calling update-rc.d?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Colin Watson]

On Wed, Jan 02, 2008 at 12:13:13AM +0100, Petter Reinholdtsen wrote:
> What about changing the default values for dh_installinit for a future
> debhelper compatibility layer, to use 'start 20 2 3 4 5 . stop 80 1 .'
> instead of 'default' when calling update-rc.d?

Some packages actually do need to shut down cleanly; in the case of a
database, for example, such a change could cause data loss. Thus I
wouldn't recommend changing the default, but perhaps providing a more
convenient single option to do that common task would be good.

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Parallel build results

[Aurelien Jarno]

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 .  
> Some statistics:
> 

>1014 succeeded, but with jobserver warnings
> 

No that DEB_BUILD_OPTIONS="parallel=n" has been superseded by
dpkg-buildpackage -j, I am trying to fix the glibc package so that it
can be built in parallel.

Unfortunately I failed to get it built on parallel (whereas with
DEB_BUILD_OPTIONS it was possible), I am getting:

make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make 
rule.

This basically means only the debian/rules file is run in parallel, the
real build is not, whereas with DEB_BUILD_OPTIONS it was the contrary.
You can imagine the difference in term of build time.

This is due to the following command:
$(call logme, -a $(log_build), $(MAKE) -C $(DEB_BUILDDIR))

where logme is defined as:

define logme
(exec 3>&1; exit `( ( ( $(2) ) 2>&1 3>&-; echo $$? >&4) | tee $(1) >&3)
4>&1`)
endef

Any idea how to get this working for parallel builds with
dpkg-buildpackage -j? I fail to see a solution.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Parallel build results

[Aurelien Jarno]

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 .  
> Some statistics:
> 
> 204 built BROKEN packages
>1408 FAILED
> 230 FAILED, even with regular build
>8986 succeeded
>1014 succeeded, but with jobserver warnings
> 
> These are not encouraging statistics, especially considering the fact that 
> there are undoubtedly many false negatives, so I'll hold off on submitting 
> bug reports for now.

Did you compare the contents of the package with and without -j? I am
almost sure some of the successfully built packages are actually not
correctly built and some files are missing.

For example I remember having seen some python packages building one 
flavour after the other in different targets. I imagine this could
result in one of the flavour being overwritten by the other, and thus
not present in the resulting .deb file.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Petter Reinholdtsen]

[Colin Watson]
> Some packages actually do need to shut down cleanly; in the case of
> a database, for example, such a change could cause data loss. Thus I
> wouldn't recommend changing the default, but perhaps providing a
> more convenient single option to do that common task would be good.

I believe it might make sense to change the default, if it only take
effect for a new debhelper compat value.  Every maintainer is supposed
to check the effects of upgrading the compat value, and we could thus
expect them to check if their init.d script need to run in runlevel 0
and 6.  If they need to stop in runlevel 0 and 6, they can always use
'start 20 2 3 4 5 . stop 80 0 1 6.'.

A new keyword might be a good option too.  multiuser is already taken
and I guess it is expected to mean 'start 20 2 3 4 5 . stop 20 1 .',
so we would want to come up with another one.  Perhaps 'normal', as in
'update-rc.d scriptname normal', to mean 'start 20 2 3 4 5 . stop 80 1
.'?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Parallel build results

[Russ Allbery]

Aurelien Jarno <[EMAIL PROTECTED]> writes:
> 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 .  Some
>> statistics:
>
>>1014 succeeded, but with jobserver warnings
>
> No that DEB_BUILD_OPTIONS="parallel=n" has been superseded by
> dpkg-buildpackage -j, I am trying to fix the glibc package so that it
> can be built in parallel.

The effect of dpkg-buildpackage -j is to set DEB_BUILD_OPTIONS.  The
package should continue to look at DEB_BUILD_OPTIONS to determine whether
parallel builds should be done.

See http://bugs.debian.org/209008 which is awaiting final reviews and
seconds and should be in the next version of Policy, and the
dpkg-buildpackage man page under the -j option.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Russ Allbery]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> I believe it might make sense to change the default, if it only take
> effect for a new debhelper compat value.  Every maintainer is supposed
> to check the effects of upgrading the compat value, and we could thus
> expect them to check if their init.d script need to run in runlevel 0
> and 6.  If they need to stop in runlevel 0 and 6, they can always use
> 'start 20 2 3 4 5 . stop 80 0 1 6.'.

I'm okay with changing it along with a debhelper compat value.  Changing
it without that sort of transition would seriously break
openafs-fileserver, among others (but I'm sure Joey wouldn't do that
anyway).

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Parallel build results

[Aurelien Jarno]

Russ Allbery a écrit :
> Aurelien Jarno <[EMAIL PROTECTED]> writes:
>> 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 .  Some
>>> statistics:
>>>1014 succeeded, but with jobserver warnings
>> No that DEB_BUILD_OPTIONS="parallel=n" has been superseded by
>> dpkg-buildpackage -j, I am trying to fix the glibc package so that it
>> can be built in parallel.
> 
> The effect of dpkg-buildpackage -j is to set DEB_BUILD_OPTIONS.  The
> package should continue to look at DEB_BUILD_OPTIONS to determine whether
> parallel builds should be done.

As far as I understand, the main effect is to call debian/rules with -j,
but it also set DEB_BUILD_OPTIONS (but I fail to see why).

Anyway, if the package continue to look to DEB_BUILD_OPTIONS, as the
make children could not communicate with the jobserver, some strange
results may appear. On architectures that have more than one flavour,
that just mean the number of jobs is actually (value of -j times number
of flavours).

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Parallel build results

[Russ Allbery]

Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Russ Allbery a écrit :

>> The effect of dpkg-buildpackage -j is to set DEB_BUILD_OPTIONS.  The
>> package should continue to look at DEB_BUILD_OPTIONS to determine
>> whether parallel builds should be done.

> As far as I understand, the main effect is to call debian/rules with -j,
> but it also set DEB_BUILD_OPTIONS (but I fail to see why).

It also sets MAKEFLAGS.  I'm not sure that part is a good idea, since
packages that don't anticipate this can't reject the provided MAKEFLAGS in
the case that the upstream build system doesn't support parallel builds.
Basically, this means that using dpkg-buildpackage -j isn't generally
safe.  It can only be used with packages that you already know support
parallel builds.

> Anyway, if the package continue to look to DEB_BUILD_OPTIONS, as the
> make children could not communicate with the jobserver, some strange
> results may appear. On architectures that have more than one flavour,
> that just mean the number of jobs is actually (value of -j times number
> of flavours).

Ah, interesting.  This is a subtlety of how make implements parallelism
that I wasn't aware of.

-- 
Russ Allbery ([EMAIL PROTECTED])   

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

[Steve Langasek]

On Wed, Jan 02, 2008 at 12:17:54AM +0100, Petter Reinholdtsen wrote:

> [Joey Hess]
> > The alternative would be changing the default for new installs, but leaving
> > existing installs as-is.

> Yes.  That might be an acceptable alternative.

> > [1] Really it probably makes sense to explicitly stop xdm during shutdown
> > anyway, since that more cleanly shuts down X.

> How does it more cleanly shut down X?  That seem to be the logic
> behind providing all the stop scripts in runlevel 0 and 6, just to
> kill a process.  There is nothing magic about sending a signal. :)

If there's an active X session, surely we would want to give an opportunity
for the session to be saved?  I'm not sure that the current behavior
actually ensures this in any case (it's probably racey in nature), but I
think it's worth bearing in mind.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Steve Langasek]

On Wed, Jan 02, 2008 at 01:46:14AM +0100, Petter Reinholdtsen wrote:

> [Colin Watson]
> > Some packages actually do need to shut down cleanly; in the case of
> > a database, for example, such a change could cause data loss. Thus I
> > wouldn't recommend changing the default, but perhaps providing a
> > more convenient single option to do that common task would be good.

> I believe it might make sense to change the default, if it only take
> effect for a new debhelper compat value.  Every maintainer is supposed
> to check the effects of upgrading the compat value, and we could thus
> expect them to check if their init.d script need to run in runlevel 0
> and 6.  If they need to stop in runlevel 0 and 6, they can always use
> 'start 20 2 3 4 5 . stop 80 0 1 6.'.

> A new keyword might be a good option too.  multiuser is already taken
> and I guess it is expected to mean 'start 20 2 3 4 5 . stop 20 1 .',
> so we would want to come up with another one.  Perhaps 'normal', as in
> 'update-rc.d scriptname normal', to mean 'start 20 2 3 4 5 . stop 80 1
> .'?

Changing the behavior of debhelper on a new compat level would be
reasonable, but changing the meaning of "update-rc.d defaults" would not,
given that this would imply maintainers must actively change their packages
in order to preserve data integrity.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Parallel build results

[Aurelien Jarno]

Russ Allbery a écrit :
> Aurelien Jarno <[EMAIL PROTECTED]> writes:
>> Russ Allbery a écrit :
> 
>>> The effect of dpkg-buildpackage -j is to set DEB_BUILD_OPTIONS.  The
>>> package should continue to look at DEB_BUILD_OPTIONS to determine
>>> whether parallel builds should be done.
> 
>> As far as I understand, the main effect is to call debian/rules with -j,
>> but it also set DEB_BUILD_OPTIONS (but I fail to see why).
> 
> It also sets MAKEFLAGS.  I'm not sure that part is a good idea, since
> packages that don't anticipate this can't reject the provided MAKEFLAGS in
> the case that the upstream build system doesn't support parallel builds.
> Basically, this means that using dpkg-buildpackage -j isn't generally
> safe.  It can only be used with packages that you already know support
> parallel builds.
> 

I think that is a problem. dpkg-buildpackage -j will be really usable
when *all* packages support parallel builds.

On the other hand, DEB_BUILD_OPTIONS=parallel=n was ignored by packages
that have not been validated by the maintainers, and used by packages
that have been tested by the maintainer. Also it was possible to use
only on some parts of the build. For example the make install part is
sometimes problematic, and mainly depends on I/O throughput of the
machine, and not CPU. This make some problems difficult to detect, as
they happen only in rare case on some machines.

Unfortunately dpkg-buildpackage now looks for DEB_BUILD_OPTIONS and call
debian/rules with -j and the value it founds in this environment
variable. That makes DEB_BUILD_OPTIONS=parallel=n useless, as it has the
same effect as dpkg-buildpackage -j.

I personally think that supporting DEB_BUILD_OPTIONS=parallel=n on some
packages is a first goal to achieve. Supporting this option in the 100
packages which take the longest to build would probably be a huge
improvement in build time of the whole archive, while being easier than
fixing all the packages in the archive. The most difficult part probably
being changing the policy (sigh) as some of them already support that,
but through a specific environment variable. Also a lot of packages
spend most of their time in the configure script for those using
autotools, and in installing/removing build-depends packages for the
others. Using make -j in those cases won't help.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Parallel build results

[Russ Allbery]

Aurelien Jarno <[EMAIL PROTECTED]> writes:

> On the other hand, DEB_BUILD_OPTIONS=parallel=n was ignored by packages
> that have not been validated by the maintainers, and used by packages
> that have been tested by the maintainer. Also it was possible to use
> only on some parts of the build. For example the make install part is
> sometimes problematic, and mainly depends on I/O throughput of the
> machine, and not CPU. This make some problems difficult to detect, as
> they happen only in rare case on some machines.
>
> Unfortunately dpkg-buildpackage now looks for DEB_BUILD_OPTIONS and call
> debian/rules with -j and the value it founds in this environment
> variable. That makes DEB_BUILD_OPTIONS=parallel=n useless, as it has the
> same effect as dpkg-buildpackage -j.
>
> I personally think that supporting DEB_BUILD_OPTIONS=parallel=n on some
> packages is a first goal to achieve. Supporting this option in the 100
> packages which take the longest to build would probably be a huge
> improvement in build time of the whole archive, while being easier than
> fixing all the packages in the archive.

I agree with this analysis.  I think the MAKEFLAGS setting in
dpkg-buildpackage should be removed and instead calling dpkg-buildpackage
with the -j option should just set the parallel=n flag in
DEB_BUILD_OPTIONS.  From there, we can leave it to package maintainers to
decide how to implement this.

If someone *really* wants to try forcing make to do a parallel build, they
can always set MAKEFLAGS themselves directly.

The only drawback that I can see is that, without special intervention by
the package, this doesn't run debian/rules itself in parallel.  But I
think the latter generates a lot of bugs and doesn't save a lot of time in
practice, so I'm okay with that.

> The most difficult part probably being changing the policy (sigh) as
> some of them already support that, but through a specific environment
> variable.

My intention is to have parallel=n be specified in Policy 3.7.4.  If you
have a moment to review the wording in Bug#209008, feedback and seconds
are certainly welcome.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Where to put in Menu?

[Russ Allbery]

Martin Meredith <[EMAIL PROTECTED]> writes:

> Looking over the lintian reports for katapult, I've noticed that the
> Apps/Tools section seems to be missing now from the menu system (yes, I
> know I'm a bit late - but better late than never!)
>
> Anyway, I can't see a suitable alternative for katapult, any ideas?
>
> (Please reply to list + myself incase I miss this in the flood of
> mailing list traffic)

It looks like katapult is a launcher, which seems like a gap in the
current menu policy.  I don't see a good category for applications that
launch other applications.

I'd probably use Applications/File Management as the closest compromise,
but I'm cc'ing the menu maintainer in case he has another suggestion.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Where to put in Menu?

[Martin Meredith]

On Tue, 2008-01-01 at 18:32 -0800, Russ Allbery wrote:
> Martin Meredith <[EMAIL PROTECTED]> writes:
> 
> > Looking over the lintian reports for katapult, I've noticed that the
> > Apps/Tools section seems to be missing now from the menu system (yes, I
> > know I'm a bit late - but better late than never!)
> >
> > Anyway, I can't see a suitable alternative for katapult, any ideas?
> >
> > (Please reply to list + myself incase I miss this in the flood of
> > mailing list traffic)
> 
> It looks like katapult is a launcher, which seems like a gap in the
> current menu policy.  I don't see a good category for applications that
> launch other applications.
> 
> I'd probably use Applications/File Management as the closest compromise,
> but I'm cc'ing the menu maintainer in case he has another suggestion.

I'm guessing that gnome-do, kommando, and some others would come under a
similar place in the menu, could it possibly be worth adding a new
subsection?



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

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

[Joey Hess]

Petter Reinholdtsen wrote:
> How does it more cleanly shut down X?  That seem to be the logic
> behind providing all the stop scripts in runlevel 0 and 6, just to
> kill a process.  There is nothing magic about sending a signal. :)

xdm's init scripts stops it by sending a TERM, waiting up to 5 seconds
for it to go away, and following with a second TERM. That's different
than sendsigs, which sends a TERM, waits up to 5 seconds and then sends a
KILL. I don't know if this difference is actually significant.

But in the case of xdm, it is significant that it happens as the very
first thing, so you can then watch the rest of the shutdown at the
console (or whatever).

I agree with you about the general case -- most daemons can just be
killed by the general process killer.

-- 
see shy jo


signature.asc
Description: Digital signature

Debian-AI

[Andrew Dougherty]

Dear Debian Developers,

There is a lot of great libre software related to the field of
Artificial Intelligence either directly or indirectly that has not
been packaged yet for Debian.

The field of Algorithmic Information Theory suggests that the
capabilities of computer systems are constrained by program size.
Therefore, a heuristic for increasing the capability of the system
would be to add additional software, which means packaging this
software, the benefits of which you know more than anyone else.

As a result of this, it has been my goal to assemble a comprehensive
software ontology of existing systems and package as many of them as
possible, ordered in such a way that the new packages can improve the
automatic creation of packages.

Packages created this way will most likely lack the love required to
pass Debian's quality assurance process and make it into the primary
Debian repository, therefore I have started my own repository.  (If I
commit to packaging the software to the quality standards of Debian,
then it is my guess that I will not be able to make all the packages I
feel are necessary in order to achieve the desired level of completion
and service.)  However, I am not opposed to this and the goal is
eventual integration into the Debian archive.

In addition to creating packages, I am also working to systematically
lobby developers of nearly free systems to release their code open
source, as well as hundreds of other task related to the goal of
creating intelligent systems through clustering, studying and applying
existing systems.

I think I would like to become a DD eventually so that I can learn
about Debian's existing systems, standards and processes.

I am requesting comment on this approach, review of my project, and
looking for guidance.  Though I have tried for 7 years, I have not
been able to make the breakthrough into the community (most likely
owing to a lack of social skills).  I tried to discuss this project on
the Debian channels, where they suggested I post to the Debian-devel
mailing list.

Would there be any interest in a Debian-AI sub-project?

My project can be found at:

   http://frdcsa.onshore.net/frdcsa

I appreciate your consideration.

Sincerely,
Andrew Dougherty

P.S.: the following systems may be of interest
radar
packager
cso
architect


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#458605: ITP: ziproxy -- a compression http proxy

[Marcos Talau]

Package: wnpp
Severity: wishlist
Owner: Marcos Talau <[EMAIL PROTECTED]>


* Package name: ziproxy
  Version : 2.4.3
  Upstream Author : Daniel Mealha Cabrita <[EMAIL PROTECTED]>
* URL : http://ziproxy.sf.net/
* License : GPL2
  Programming Lang: C
  Description : a compression http proxy

ziproxy is a forwarding (non-caching) proxy that gzips text and HTML files,
and reduces the size of images by converting them to lower quality JPEGs. 
It is intended to increase the speed for low-speed Internet connections and
it's suitable for both home and professional usage. ziproxy is fully 
configurable and also features transparent proxy mode, preemptive name 
resolution, operation in either daemon mode or (x)inetd mode, a detailed 
access log with compression statistics, basic authentication, and more.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-rc5-g75b8c133 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Where to put in Menu?

[Martin Meredith]

Hi there,

Looking over the lintian reports for katapult, I've noticed that the
Apps/Tools section seems to be missing now from the menu system (yes, I
know I'm a bit late - but better late than never!)

Anyway, I can't see a suitable alternative for katapult, any ideas?

(Please reply to list + myself incase I miss this in the flood of
mailing list traffic)

Regards,
Mez


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

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

[Joey Hess]

Petter Reinholdtsen wrote:
> What about changing the default values for dh_installinit for a future
> debhelper compatibility layer, to use 'start 20 2 3 4 5 . stop 80 1 .'
> instead of 'default' when calling update-rc.d?

Then you'd have to use 'dh_installinit -- defaults' to get the
non-default behavior of running the stop script. That's counterintuitive.

The issue of whether to remove the old stop links remains, and if we
decide to remove them, debhelper can't really handle that and
maintainers would have to manually insert the code into their init
scripts when changing debhelper compatability levels.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#458608: ITP: python-memcached -- pure python memcached client

[Christopher Schmidt]

Package: wnpp
Severity: wishlist
Owner: Christopher Schmidt <[EMAIL PROTECTED]>


* Package name: python-memcached
  Version : 1.40 
  Upstream Author : Sean Reifschneider <[EMAIL PROTECTED]> 
* URL : http://www.tummy.com/Community/software/python-memcached/ 
* License : Python License
  Programming Lang: Python 
  Description : pure python memcached client
This software is a 100% Python interface to the memcached memory cache
daemon.  It is the client side software which allows storing values in
one or more, possibly remote, memcached servers. 

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#140230: massey withdrew

[Addie Lottff]

Greetings,
dont you expect gigantic slong
http://www.saltutieod.com

Courtney




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#166937: syrinx desire

[Cliffordw Landisl]

Hi,
would you have gigantic member
http://www.quarshse.com

Gavin




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Steve Langasek]

On Wed, Dec 26, 2007 at 01:11:40PM +, Neil Williams wrote:
> > > ... until both the application and libfoo are rebuilt. So the issue
> > > here is triggering rebuilds of reverse dependencies of libbar?

> > No.  That doesn't cause previously released binaries to blink out of
> > existence.

> > What's required is to ensure that there's a package rename each time
> > libfoo's ABI changes, including when the libfoo ABI change is caused by type
> > changes in the underlying lib.  This is essentially the general case of the
> > c102, c2, c2a, and ldbl transitions that we've been through for compiler
> > changes over the past few years; in theory we should be able to accomplish
> > these transitions for libraries with fewer reverse-dependencies than
> > libstdc++ with significantly less pain, as long as library maintainers are
> > forewarned.

> > But once the package name change is handled, the rebuild of reverse-deps
> > follows naturally.

> That sounds a lot better than the original idea of incorporating the
> entire dependency chain into the package name. 

> I think I'm doing this already - if libfoo1 implements and exports types
> from libbar2 and libbar2 moves to libbar3, I would expect to have to
> port libfoo to libbar3 and this would usually cause a SONAME bump in
> libfoo.

> So could I ask, from an upstream perspective, what kind of changes in
> the underlying lib might *not* cause such a port and therefore end up
> with libfoo1 still being buildable against libbar3 yet *still* require a
> SONAME bump to accommodate the transition?

Succinctly addressed by Robert.

> Have I got these possible scenarios correct:

> 1. libfoo depends on libbar2 without exporting libbar symbols. libfoo
> can migrate to libbar3 with internal code changes and if these do not
> require changing any libfoo interfaces, libfoo needs no SONAME bump.

No, "exporting libbar symbols" is not the right line to draw.  The right
line is the one I already identified, namely, "libfoo uses some of libbar's
types in its own exported ABI".

> Does libfoo need to use versioned symbols to cope with this

No, libbar does, as the library which has other libraries for
reverse-dependencies.

> There needs to be some check on the application that compares the
> dependency chain as well as the dependency list in the package itself.
> lintian cannot do that.

Not if libbar uses symbol versioning.

> 2. libfoo depends on libbar2 and exports some libbar symbols in
> libfoo-dev. libfoo can migrate to libbar3 with only internal code
> changes because it only exports a portion of the libbar API that has not
> actually been changed in the libbar2->libbar3 transition. libfoo needs
> to export libbar in the libfoo --libs data. Is a SONAME bump needed in
> libfoo even though *none* of the libfoo interfaces have changed? As
> upstream for libfoo, I would not normally make a SONAME bump in this
> situation. Would it be better to rename the Debian package without
> bumping the SONAME, e.g. libfoo1-0->libfoo1-1 ? Wouldn't this cause
> unnecessary rebuilds of applications that only depend on libfoo and not
> libbar?

If libfoo's exported ABI hasn't changed, then any package name or soname
change is gratuitous and should be avoided.

> 3. libfoo depends on libbar2 and needs to make changes to its own
> interfaces to cope with the libbar transition or needs to export symbols
> from the new libbar API and therefore makes a SONAME bump. No problem
> here except ensuring that applications transition to both API's at the
> same time. Can be enforced by making libbar-dev conflict with the old
> libfoo-dev or making the new libfoo-dev depend on the new libbar-dev
> version.

Requires disruptive name changes to libbar-dev which affect all packages
that build-depend on it, and is therefore again inferior to implementing
symbol versions up front.

> > > Maybe I've got this wrong but there would appear to be a few methods to
> > > fix this:
> > > 1. Incorporating the libbar SONAME into the libfoo package SONAME - as
> > > Simon Richter recommended - this could quickly end up with
> > > libany1-foo2-bar2-baz0-base4-pango0-... etc and I'm not convinced that
> > > this would actually help anyone if, for example, libbaz0 migrates to
> > > libbaz1 in a way that completely breaks libbar2.

> > Then either libbar2 becomes libbar3 at the same time, or libbar becomes
> > unsupported (and the stack above it has to be ported or else it's not
> > releasable), or libbaz needs to support symbol versioning to permit
> > coexistence of the two versions in the same address space.

> Even if the actual fix for libbar2 is only internal?

Then that would eliminate the first option, leaving only the other two.

> Yet the problem isn't in libbaz either, so why force libbaz to implement
> versioned symbols through (apparently) no fault of its own?

Because *all* libraries which have other libs as reverse-dependencies should
implement symbol versioning, precisely as the shortest path for re

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

[Petter Reinholdtsen]

[Joey Hess]
> Then you'd have to use 'dh_installinit -- defaults' to get the
> non-default behavior of running the stop script. That's
> counterintuitive.

Well.  As 'update-rc.d scriptname default' will have to keep its old
behavoiur, to avoid breaking a lot of functioning packages, I see no
other sensible way to change the default for most packages.

> The issue of whether to remove the old stop links remains, and if we
> decide to remove them, debhelper can't really handle that and
> maintainers would have to manually insert the code into their init
> scripts when changing debhelper compatability levels.

Yes.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]