Re: Bug#473354: ITP: winhardware -- hardware summary report from a Win32 host

[Bernd Zeimetz]

Joel Franco wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Joel Franco <[EMAIL PROTECTED]>
> 
> 
> * Package name: winhardware
>   Version : 0.0.14
>   Upstream Author : Joel Franco <[EMAIL PROTECTED]>
> * URL : Not yet
> * License : GPL
>   Programming Lang: shell script
>   Description : hardware summary report from a Win32 host
> 
> Gets the basic hardware report from a Win32 computer including
> processor, last user, memory, disk, motherboard, network interface card
> and others. Uses the WMI interface.

are you going to use wmic and/or winexe for that? Then I'd suggest to
add teh script to the wmi-client package instead of wasting a full
package for a single shellscript.

Cheers,

Bernd


-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Should we have two versions of Boost in the archive?

[Steve M. Robbins]

Hello,

A new version (1.35) of the Boost library collection was released
yesterday.  I'd like to get it packaged for Debian ASAP.  The question
is: whether to simply replace the existing version (1.34.1) as we have
always done, or to have the old and new both available in the library?

In the past, we've always supported a single version of boost.  But
changing versions seems to cause a lot of convulsions, so Domenico
recently proposed that we have two versions of Boost sources in the
archive and version each of the 13 -dev packages.


On Wed, Feb 27, 2008 at 11:40:30AM +0100, Domenico Andreoli wrote:

> It may sound even better if multiple Boost versions were considered,
> packaging them in versioned source packages (ie boost-1.34.1,
> boost-1.35.0). Respective -dev packages should then be also versioned
> and conflicting each other, as the mostly undecorated symlinks there
> provided. Having boost-defaults driving the default Boost and Python
> versions and the completely undecorated symlinks.
> 
> This, for instance, would allow Boost 1.35.0 in lenny while 1.34.1
> being the default one. I frankly doubt a full transition to 1.35.0
> would happen before the release of lenny.


For some large systems (e.g. GCC, Qt, VTK), I see the utility of this
approach in that each major version typically brings with it
significant source incompatibility and forces client code to adopt.
Some client code may not adapt immediately and can continue to build
with the older version.

I don't have a good sense whether this is the case with Boost.  It may
simply be that a Boost transition is a nuisance because it forces the
recompilation of many client libraries, which in turn are widely used
and therefore ends up involving a lot of packages.  Or, indeed,
whether this distinction makes no difference in deciding how to
proceed.

I'd appreciate your thoughts on whether having two Boost source
versions in Debian is worth the packaging effort.

Thanks,
-Steve

P.S.  For the new version of Boost, I plan to remove the compiler 
version from the library SONAMES.


signature.asc
Description: Digital signature

Re: Bug#473354: ITP: winhardware -- hardware summary report from a Win32 host

[Joel Franco]

On Sun 30 Mar 08 14:38, Bernd Zeimetz wrote:
>Joel Franco wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Joel Franco <[EMAIL PROTECTED]>
>> 
>> 
>> * Package name: winhardware
>>   Version : 0.0.14
>>   Upstream Author : Joel Franco <[EMAIL PROTECTED]>
>> * URL : Not yet
>> * License : GPL
>>   Programming Lang: shell script
>>   Description : hardware summary report from a Win32 host
>> 
>> Gets the basic hardware report from a Win32 computer including
>> processor, last user, memory, disk, motherboard, network interface card
>> and others. Uses the WMI interface.
>
>are you going to use wmic and/or winexe for that? Then I'd suggest to
>add teh script to the wmi-client package instead of wasting a full
>package for a single shellscript.

Hi Bernd,

I have no relationship with the wmi-client package nor knows the
mainteiner. To agree with your opinion, i should work close to that
mantainer and this could make the work a lot harder in the mean that i
have to commnuicate with him.

My work is in get just the selected hardware data from the Windows host
and whis is another "layer" of the "how" the communication runs.

Ok, the shell script is small and simple, but this is a simple task :)

I would to hear others opinions about your opinion.

Thank You.

Joel Franco

>
>Cheers,
>
>Bernd
>
>
>-- 
>Bernd Zeimetz
><[EMAIL PROTECTED]> 


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

Re: Should we have two versions of Boost in the archive?

[Pierre Habouzit]

On Sun, Mar 30, 2008 at 05:22:45PM +, Steve M. Robbins wrote:
> Hello,
> 
> A new version (1.35) of the Boost library collection was released
> yesterday.  I'd like to get it packaged for Debian ASAP.

  You're aware that we're trying to release and that you shouldn't
upload things you are not sure will transition in time without
disturbing other transitions too much ?

  Is there any immediate gain to those new libraries over 1.34.1 that
warrant such a haste ?

> The question is: whether to simply replace the existing version
> (1.34.1) as we have always done, or to have the old and new both
> available in the library?

  There should definitely be one only given that if I read the version
number correctly, 1.35 shouldn't be *that* disruptive wrt 1.34.1.

> In the past, we've always supported a single version of boost.  But
> changing versions seems to cause a lot of convulsions,

  Well the proper approach then, is to package 1.35 locally, and rebuild
its rdeps to have a clue about the wideness of the breakages. But
throwing into a new transition with a package as painful as Boost is to
transition, withouth having a single clue of what will happen is
unconsciousness.


> P.S.  For the new version of Boost, I plan to remove the compiler 
> version from the library SONAMES.

  *THAT* would be an excellent thing to do, and if we are going to
transition, it seems opportune to do it at the same time.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpQD2R239d4i.pgp
Description: PGP signature

Re: Bug#473354: ITP: winhardware -- hardware summary report from a Win32 host

[Julien Cristau]

On Sun, Mar 30, 2008 at 14:26:48 -0300, Joel Franco wrote:

> I would to hear others opinions about your opinion.
> 
I don't think adding a package for a simple shell script makes any
sense.

Cheers,
Julien


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

Re: Bug#473354: ITP: winhardware -- hardware summary report from a Win32 host

[Bernd Zeimetz]

Hi,

> I have no relationship with the wmi-client package nor knows the
> mainteiner. To agree with your opinion, i should work close to that
> mantainer and this could make the work a lot harder in the mean that i
> have to commnuicate with him.

uh, ntot really. You've just sent him an email ;)
The package is maintained by me in the Zenoss team... If you want to
provide such a script, as examples or for /usr/bin (with manpage then
please), I could give you access to the svn, so you can maintain it in
the debian directory of the package, not a big problem.

Cheers,

Bernd
-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: [pkg-boost-devel] Should we have two versions of Boost in the archive?

[Steve M. Robbins]

On Sun, Mar 30, 2008 at 07:38:14PM +0200, Pierre Habouzit wrote:
> On Sun, Mar 30, 2008 at 05:22:45PM +, Steve M. Robbins wrote:
> > Hello,
> > 
> > A new version (1.35) of the Boost library collection was released
> > yesterday.  I'd like to get it packaged for Debian ASAP.
> 
>   You're aware that we're trying to release and that you shouldn't
> upload things you are not sure will transition in time without
> disturbing other transitions too much ?

I'm aware of the release, yes.  I should have spelled this out in more
detail previously: to me, the "P" in "ASAP" means "possible, given the
impact of a Boost transition on the impending Debian release."  If the
release folks consider it too risky, it will happen post-release.


>   Is there any immediate gain to those new libraries over 1.34.1 that
> warrant such a haste ?

There are a number of interesting new libraries; e.g. asio, fusion,
math, mpi, and significant updates to existing libraries [1].  That is
compelling to me, but I concede others may have a different view.

[1] http://www.boost.org/users/news/version_1_35_0


> > The question is: whether to simply replace the existing version
> > (1.34.1) as we have always done, or to have the old and new both
> > available in the library?
> 
>   There should definitely be one only given that if I read the version
> number correctly, 1.35 shouldn't be *that* disruptive wrt 1.34.1.

Unfortunately, this is not the case.  Boost is not guaranteeing ABI
compatibility across releases, i.e. from 1.34 to 1.35.  So don't read
this as "major.minor" in the traditional sense.  The SONAME has the
complete version in the string; i.e. "1.34", "1.35".

So with this in mind, let me ask my question slightly differently:

Is the API change dramatic enough to warrant keeping two versions
of Boost sources in the archive?

Thanks,
-Steve


signature.asc
Description: Digital signature

Re: [pkg-boost-devel] Should we have two versions of Boost in the archive?

[Steve Langasek]

On Sun, Mar 30, 2008 at 02:59:07PM -0500, Steve M. Robbins wrote:
> Unfortunately, this is not the case.  Boost is not guaranteeing ABI
> compatibility across releases, i.e. from 1.34 to 1.35.  So don't read
> this as "major.minor" in the traditional sense.  The SONAME has the
> complete version in the string; i.e. "1.34", "1.35".

> So with this in mind, let me ask my question slightly differently:

> Is the API change dramatic enough to warrant keeping two versions
> of Boost sources in the archive?

So what are the API changes?  ABI change != API change.  Are there
significant API changes that you know of that will break rebuilds of the
existing reverse-dependencies?

-- 
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]

triggers wishlist

[Joey Hess]

dpkg in experimental supports triggers now, and in many cases trigger
support can be added to packages without creating a hard dependency on
a new version of dpkg.

Things I want to see use triggers, in approximate priority order:

- scrollkeeper
This is a huge speed pig, and d-i has hacks to disable it and 
run it at the end that I would love to be able to remove.
dpkg's triggers.txt has a plan for triggerizing it
- tetex stuff
Also very slow. Maintainers already plan to use triggers.
- update-menus 
Run by zillions of postinsts and postrms, many of these can be
gotten rid of entirely by using triggers, which is a big
complexity win.
I have written a patch for initial trigger support in menu. (#473467)
- ldconfig
Seems to be some uncertainty about where it's possible to
triggerize this safely and reliably.
- update-mime
- update-mime-database
We could probably speed up desktop installs by about 1 minute by
triggerizing these.
- update-icon-caches
- update-desktop-database
These are not very slow, nor used by a great many packages,
but triggerizing them would allow getting rid of dh_icons and 
dh_desktop eventually, which I would appreciate.
- install-info
Currnently it has to be told which info file has changed, but
that could easily be removed. Triggerizing this would simplify
some maintainer scripts. (Only ones that don't need to pass
install-info any options.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: triggers wishlist

[Mike Bird]

On Sun March 30 2008 13:25:15 Joey Hess wrote:
> dpkg in experimental supports triggers now

THANK YOU IAN for persisting with triggers despite the tedious delays by
blistering incompetents.  And thanks Joey for the interesting use cases.

--Mike Bird


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

Re: triggers wishlist

[Raphael Hertzog]

On Sun, 30 Mar 2008, Mike Bird wrote:
> On Sun March 30 2008 13:25:15 Joey Hess wrote:
> > dpkg in experimental supports triggers now
> 
> THANK YOU IAN for persisting with triggers despite the tedious delays by
> blistering incompetents.  And thanks Joey for the interesting use cases.

Ian has nothing to do with the experimental upload nor with the work of
merging his code in dpkg. 

Guillem did all of this. Thank you to the people who have been supportive.
And thanks to Guillem for doing the work despite the unfriendly atmosphere
that some managed to create.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: triggers wishlist

[Pierre Habouzit]

On Sun, Mar 30, 2008 at 08:25:15PM +, Joey Hess wrote:
> - update-menus 
>   Run by zillions of postinsts and postrms, many of these can be
>   gotten rid of entirely by using triggers, which is a big
>   complexity win.
>   I have written a patch for initial trigger support in menu. (#473467)

  I thought this one had a custom hack already ? It does not means that
it could not be dropped alltogether though.

> - ldconfig
>   Seems to be some uncertainty about where it's possible to
>   triggerize this safely and reliably.

  More importantly, since recently, ldconfig uses a second cache, and
is way faster than before. It seems less than safe to "optimize"
ldconfig through triggers, for a very little gain in the end.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpvTUKRQZsjm.pgp
Description: PGP signature

Re: [pkg-boost-devel] Should we have two versions of Boost in the archive?

[Pierre Habouzit]

On Sun, Mar 30, 2008 at 07:59:07PM +, Steve M. Robbins wrote:
> On Sun, Mar 30, 2008 at 07:38:14PM +0200, Pierre Habouzit wrote:
> > On Sun, Mar 30, 2008 at 05:22:45PM +, Steve M. Robbins wrote:
> > > The question is: whether to simply replace the existing version
> > > (1.34.1) as we have always done, or to have the old and new both
> > > available in the library?
> > 
> >   There should definitely be one only given that if I read the version
> > number correctly, 1.35 shouldn't be *that* disruptive wrt 1.34.1.
> 
> Unfortunately, this is not the case.  Boost is not guaranteeing ABI
> compatibility across releases, i.e. from 1.34 to 1.35.  So don't read
> this as "major.minor" in the traditional sense.  The SONAME has the
> complete version in the string; i.e. "1.34", "1.35".

  I *know* that, I obviously meant *API* disruptivity, that's why I
spoke about private rebuilds of its rdeps to evaluate the migration risk
factor in the first place :)


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org



pgpxYVigrv2Ha.pgp
Description: PGP signature

Re: triggers wishlist

[Amaya]

Raphael Hertzog wrote:
> And thanks to Guillem for doing the work despite the unfriendly atmosphere
> that some managed to create.

Ditto.

-- 
  ·''`. A waste is a terrible thing to mind!
 : :' :
 `. `'
   `-Proudly running (unstable) Debian GNU/Linux


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

Re: triggers wishlist

[Michael Biebl]

Joey Hess wrote:
> dpkg in experimental supports triggers now, and in many cases trigger
> support can be added to packages without creating a hard dependency on
> a new version of dpkg.
> 
> Things I want to see use triggers, in approximate priority order:

[..]

> - update-icon-caches
> - update-desktop-database
>   These are not very slow, nor used by a great many packages,
>   but triggerizing them would allow getting rid of dh_icons and 
>   dh_desktop eventually, which I would appreciate.

Sounds interesting.
What would have a maintainer to do, to support triggers?
As a lot of Gnome/KDE packages use cdbs, would fixing kde.mk/gnome.mk be
sufficient?

> - install-info
>   Currnently it has to be told which info file has changed, but
>   that could easily be removed. Triggerizing this would simplify
>   some maintainer scripts. (Only ones that don't need to pass
>   install-info any options.)
> 

- insserv/update-rc.d
Looks like a possible candidate too (without knowing much about triggers).

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: triggers wishlist

[Hubert Chathi]

On Sun, 30 Mar 2008 16:25:15 -0400, Joey Hess <[EMAIL PROTECTED]> said:

> dpkg in experimental supports triggers now, and in many cases trigger
> support can be added to packages without creating a hard dependency on
> a new version of dpkg.

Yay!

> Things I want to see use triggers, in approximate priority order:

[... snip very nice list ...]

How about defoma?  fontconfig?

-- 
Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED]
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


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

Re: triggers wishlist

[Joey Hess]

Pierre Habouzit wrote:
> On Sun, Mar 30, 2008 at 08:25:15PM +, Joey Hess wrote:
> > - update-menus 
> > Run by zillions of postinsts and postrms, many of these can be
> > gotten rid of entirely by using triggers, which is a big
> > complexity win.
> > I have written a patch for initial trigger support in menu. (#473467)
> 
>   I thought this one had a custom hack already ? It does not means that
> it could not be dropped alltogether though.

The custom hack depends on all postinsts running update-menus, which is
a large amount of unnecessary code. After re-reading the code today, I 
also belive it's got race conditions (#473464), amoung other problems.

> > - ldconfig
> > Seems to be some uncertainty about where it's possible to
> > triggerize this safely and reliably.
> 
>   More importantly, since recently, ldconfig uses a second cache, and
> is way faster than before. It seems less than safe to "optimize"
> ldconfig through triggers, for a very little gain in the end.

It does seem to take only 0.1 seconds from a warm cache here.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: triggers wishlist

[Rene Engelhard]

Hi,

Joey Hess wrote:
> Things I want to see use triggers, in approximate priority order:
> 
> - scrollkeeper
>   This is a huge speed pig, and d-i has hacks to disable it and 
>   run it at the end that I would love to be able to remove.
>   dpkg's triggers.txt has a plan for triggerizing it
> - tetex stuff
>   Also very slow. Maintainers already plan to use triggers.
> - update-menus 
>   Run by zillions of postinsts and postrms, many of these can be
>   gotten rid of entirely by using triggers, which is a big
>   complexity win.
>   I have written a patch for initial trigger support in menu. (#473467)
> - ldconfig
>   Seems to be some uncertainty about where it's possible to
>   triggerize this safely and reliably.
> - update-mime
> - update-mime-database
>   We could probably speed up desktop installs by about 1 minute by
>   triggerizing these.
> - update-icon-caches
> - update-desktop-database
>   These are not very slow, nor used by a great many packages,
>   but triggerizing them would allow getting rid of dh_icons and 
>   dh_desktop eventually, which I would appreciate.
> - install-info
>   Currnently it has to be told which info file has changed, but
>   that could easily be removed. Triggerizing this would simplify
>   some maintainer scripts. (Only ones that don't need to pass
>   install-info any options.)

Maybe also fc-cache calls?

Regards,

Rene


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

Re: triggers wishlist

[Michael Biebl]

Petter Reinholdtsen wrote:
> [Michael Biebl]
>> - insserv/update-rc.d
>> Looks like a possible candidate too (without knowing much about
>> triggers).

I have to add, that I don't know much about insserv either ;-)

> 
> I doubt it, as boot script updates need to be done in dependency
> order, and reject the package if installing a script would introduce a
> loop, but am open for explanations showing me to be wrong. :)

I don't understand, why it shouldn't be possible, that a single
update-rc.insserv run, reoders *all* init scripts in one go. You could
still skip the ones, which will cause loops or have no dependency
information.


Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: triggers wishlist

[Petter Reinholdtsen]

[Michael Biebl]
> - insserv/update-rc.d
> Looks like a possible candidate too (without knowing much about
> triggers).

I doubt it, as boot script updates need to be done in dependency
order, and reject the package if installing a script would introduce a
loop, but am open for explanations showing me to be wrong. :)

I do not know very much about triggers either. :)

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: triggers wishlist

[Joey Hess]

Rene Engelhard wrote:
> Maybe also fc-cache calls?

I don't have many of those here, but if desired I think it could be made
to use triggers, yes.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: triggers wishlist

[Joey Hess]

Hubert Chathi wrote:
> > Things I want to see use triggers, in approximate priority order:
> 
> [... snip very nice list ...]
> 
> How about defoma?  fontconfig?

defoma-app and defoma-font act on a specific application/font that is being
installed/removed. Converting this kind of thing to use triggers is more
difficult than things like fc-cache that just scan all available files.
I am not familiar enough with defoma to speculate about whether they
could be redesigned to be suitable for use by triggers.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: triggers wishlist

[Joey Hess]

Michael Biebl wrote:
> > - update-icon-caches
> > - update-desktop-database
> > These are not very slow, nor used by a great many packages,
> > but triggerizing them would allow getting rid of dh_icons and 
> > dh_desktop eventually, which I would appreciate.
> 
> Sounds interesting.
> What would have a maintainer to do, to support triggers?
> As a lot of Gnome/KDE packages use cdbs, would fixing kde.mk/gnome.mk be
> sufficient?

The maintainer of those scripts would need to change them to use
triggers, dpkg's triggers.txt explains how, and it's easy for this kind
of program.

The maintainers of packages using them then stop running them manually
in the maintainer scripts. This could be accomplished by a debhelper
modification.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: triggers wishlist

[Cyril Brulebois]

On 30/03/2008, Michael Biebl wrote:
> I don't understand, why it shouldn't be possible, that a single
> update-rc.insserv run, reoders *all* init scripts in one go. You could
> still skip the ones, which will cause loops or have no dependency
> information.

I guess the algo is currently “there's no loop; try and add foo; if a
loop is introduced, foo is guilty; otherwise, be happy”. If you don't
have the “we're trying to add foo” bit, I guess it's hard (if possible
at all) to find which package(s) is/are guilty.

-- 
Cyril Brulebois


pgpl0qzvelLLA.pgp
Description: PGP signature

Re: triggers wishlist

[Sune Vuorela]

On 2008-03-30, Joey Hess <[EMAIL PROTECTED]> wrote:
>
> --0IvGJv3f9h+YhkrH
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> Michael Biebl wrote:
>> > - update-icon-caches
>> > - update-desktop-database
>> >These are not very slow, nor used by a great many packages,
>> >but triggerizing them would allow getting rid of dh_icons and=20
>> >dh_desktop eventually, which I would appreciate.
>>=20
>> Sounds interesting.
>> What would have a maintainer to do, to support triggers?
>> As a lot of Gnome/KDE packages use cdbs, would fixing kde.mk/gnome.mk be
>> sufficient?

I think kde.mk is mostly used to set correct autofoo arguments and such.
Not about the postinst snippets, where kde.mk just relies on the cdbs
debhelper.mk bruteforcing.

> The maintainers of packages using them then stop running them manually
> in the maintainer scripts. This could be accomplished by a debhelper
> modification.

A debhelper modification and a binNMU of related packages ? ;)

Maybe having the trigger enabled dh_foo fill in misc:Depends with a
versioned dependency on a trigger aware dpkg ?

/Sune


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

Re: triggers wishlist

[Mike Bird]

On Sun March 30 2008 14:01:33 Raphael Hertzog wrote:
> On Sun, 30 Mar 2008, Mike Bird wrote:
> > THANK YOU IAN for persisting with triggers despite the tedious delays by
> > blistering incompetents.  And thanks Joey for the interesting use cases.
>
> Ian has nothing to do with the experimental upload nor with the work of
> merging his code in dpkg.
>
> Guillem did all of this. Thank you to the people who have been supportive.
> And thanks to Guillem for doing the work despite the unfriendly atmosphere
> that some managed to create.

Raphaël,

Designing and implementing triggers was a lot more work, and a lot more
serious work, than merely merging a git branch.  Once you start to learn
some programming you'll understand the difference.

I'm glad that Guillem finally found time out from reformatting code to
merge Ian's work.  Guillem could have blocked triggers indefinitely but
to thank Guillem for ONLY delaying triggers by eight or ten months is hokum.

--Mike Bird

Re: triggers wishlist

[Darren Salt]

I demand that Michael Biebl may or may not have written...

> Joey Hess wrote:
>> dpkg in experimental supports triggers now, and in many cases trigger
>> support can be added to packages without creating a hard dependency on a
>> new version of dpkg.
>> Things I want to see use triggers, in approximate priority order:
[snip]
> - insserv/update-rc.d
> Looks like a possible candidate too (without knowing much about triggers).

Updating xine-lib front ends' desktop files at install time or when
installing or removing some libxine{1,2}-*. (Bug 472870, should anybody be
interested.)

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   http://www.youmustbejoking.demon.co.uk/progs.packages.html>

Is this really happening?


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

Re: triggers wishlist

[Robert Collins]

On Mon, 2008-03-31 at 00:54 +0200, Cyril Brulebois wrote:
> On 30/03/2008, Michael Biebl wrote:
> > I don't understand, why it shouldn't be possible, that a single
> > update-rc.insserv run, reoders *all* init scripts in one go. You could
> > still skip the ones, which will cause loops or have no dependency
> > information.
> 
> I guess the algo is currently “there's no loop; try and add foo; if a
> loop is introduced, foo is guilty; otherwise, be happy”. If you don't
> have the “we're trying to add foo” bit, I guess it's hard (if possible
> at all) to find which package(s) is/are guilty.

Huh, pretty straight forward - use tarjans method, get the strongly
connected sets, and you can dump out the loops immediately. If you want
to be able to say 'package X is at fault' - well, adding packages one by
one does not tell you that - the loop exists in the archive, adding
packages one by one only tells you when you have pulled in enough to
show the loop.

-Rob

-- 
GPG key available at: .


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

Re: triggers wishlist

[Joey Hess]

Suggested off-list: update-grub

I agree that this would be nice. Particularly if many old kernel
packages are removed, the multiple update-grub calls become annying.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: triggers wishlist

[Michael Biebl]

Sune Vuorela wrote:

>> Michael Biebl wrote:
 - update-icon-caches
 - update-desktop-database
These are not very slow, nor used by a great many packages,
but triggerizing them would allow getting rid of dh_icons and=20
dh_desktop eventually, which I would appreciate.
>>> =20
>>> Sounds interesting.
>>> What would have a maintainer to do, to support triggers?
>>> As a lot of Gnome/KDE packages use cdbs, would fixing kde.mk/gnome.mk be
>>> sufficient?
> 
> I think kde.mk is mostly used to set correct autofoo arguments and such.
> Not about the postinst snippets, where kde.mk just relies on the cdbs
> debhelper.mk bruteforcing.
> 
>> The maintainers of packages using them then stop running them manually
>> in the maintainer scripts. This could be accomplished by a debhelper
>> modification.
> 
> A debhelper modification and a binNMU of related packages ? ;)
> 
> Maybe having the trigger enabled dh_foo fill in misc:Depends with a
> versioned dependency on a trigger aware dpkg ?

If I read the triggers documentation correctly, the situation is a bit
different (please correct my, if I'm wrong. I just quickly glanced at
triggers.txt)
update-icon-caches/update-desktop-database would have to be made
triggers-aware and install a triggers control file
(e.g. interest /usr/share/icons or interest /usr/share/applications [1])

A package installing icons or a desktop file, would remove all calls to
dh_desktop/dh_icons (that's why cdbs kde.mk/gnome.mk would have to be
updated to remove the dh_desktop/dh_icons calls). The triggers would be
activated by installing files into the above directories.

An alternative would be, to keep dh_desktop/dh_icons around, to provide
backwards compatibility (if triggers-aware dpkg is installed, they would
be simple no-ops, otherwise they would behave as before).

Cheers,
Michael

[1] Will changes to subdirectories (e.g /usr/share/applications/kde)
also lead to a trigger, or would one have to register all subdirectories
recursively?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: triggers wishlist

[Michael Biebl]

Joey Hess wrote:
> Suggested off-list: update-grub
> 
> I agree that this would be nice. Particularly if many old kernel
> packages are removed, the multiple update-grub calls become annying.
> 

Add update-initramfs to that list. It can take quite some time to
regenerate the initramfs. Packages that update the initramfs are e.g.
udev, cryptsetup or uswsusp, splashy/usplash

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: triggers wishlist

[Joey Hess]

Michael Biebl wrote:
> [1] Will changes to subdirectories (e.g /usr/share/applications/kde)
> also lead to a trigger

The docs don't seem to say, but my tests show that registering interest
does cause trigger updates for files in subdirs.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#473354: ITP: winhardware -- hardware summary report from a Win32 host

[Joel Franco]

Hi Bernd,

I didn't know about Zenoss, but after visit the site and the wikipedia,
i understand why the wmi-client is part of the infracstructure. It
appears to be a great software, i will try it to manage my more than 30
servers from my clients.

About the inclusion of winhardware in the wmi-client tree I still do not
think it positive by the reasons that is said before. However, if it's
one way to publish my work i accept your offer :) Would you give me
access to the package svn?

Thank you

-- 
|
| Joel Franco Guzmán  .''`.
|  self-powered by   : :' :
|   Debian Linux `. `' 
|at BraSil `- 

On Sun 30 Mar 08 20:49, Bernd Zeimetz wrote:
>Hi,
>
>> I have no relationship with the wmi-client package nor knows the
>> mainteiner. To agree with your opinion, i should work close to that
>> mantainer and this could make the work a lot harder in the mean that i
>> have to commnuicate with him.
>
>uh, ntot really. You've just sent him an email ;)
>The package is maintained by me in the Zenoss team... If you want to
>provide such a script, as examples or for /usr/bin (with manpage then
>please), I could give you access to the svn, so you can maintain it in
>the debian directory of the package, not a big problem.
>
>Cheers,
>
>Bernd
>-- 
>Bernd Zeimetz
><[EMAIL PROTECTED]> 
>
>
>-- 
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


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

Re: triggers wishlist

[Paul Wise]

On Mon, Mar 31, 2008 at 4:25 AM, Joey Hess <[EMAIL PROTECTED]> wrote:

>  - ldconfig
> Seems to be some uncertainty about where it's possible to
> triggerize this safely and reliably.

Ubuntu seems to have managed it OK? I imagine it would be a gain for
slower systems too?

Before the recent pango update in sid, I had tons of fonts installed
and fc-cache was a pain, so I'd definitely appreciate that once I have
time to figure out which font caused my font rendering issues.

Triggers would be really useful for module-assistant/dkms too I
imagine - autobuild a bunch of modules for each kernel headers package
installed. Dunno if that would be possible though.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

World Best And bigget thing

[This is Naren Sharma]

World Best and biggest thing ,have a look
 http://narendrasharma.wordpress.com

Re: triggers wishlist

[Petter Reinholdtsen]

[Michael Biebl]
> I don't understand, why it shouldn't be possible, that a single
> update-rc.insserv run, reoders *all* init scripts in one go. You
> could still skip the ones, which will cause loops or have no
> dependency information.

Well, there are two things that need to be done as insserv work today:

 - Call update-rc.d in dependency order when adding new scripts to the
   boot sequence (one call is not going to work).  It refuses to
   install a script (and in consequence, the package) if the scripts
   hard dependencies are not already inserted into the boot sequence.

 - Refuse to install a package that introduces a dependency loop,
   while allowing those that do not introduce a loop to install, to
   avoid getting an unstable boot sequence (as in, there is no way to
   know how to order the scripts involved in a loop).

I'm not aware of triggers being able to do that.  Besides, one need to
be very careful when changing the boot sequence, to make sure the
machine stay bootable. :)

Happy hacking,
-- 
Petter Reinholdtsen


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