Please see this site in Subject
Please see this site in Subject
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
* 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 ca
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 shutd
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 a
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-ve
[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 oth
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 to
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 upda
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' opt
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]
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
[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, bu
[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
[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.
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
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 .
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 .
[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 be
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
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 in
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
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
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 st
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
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
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
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 katap
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
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 sec
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
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
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 + my
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 b
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
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]
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]
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.
> >
[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
othe
40 matches
Mail list logo
