Re: Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Philipp Kern 
On Mon, Jul 23, 2012 at 10:31:43PM -0400, Filipus Klutiero wrote:
> Please try using complete sentences. While you're at it,
> constructive messages would be more productive than name-calling.

If you think that your messages are constructive, well, you're wrong. You're
repeating the same arguments over and over again, despite not being a Debian
Developer (yes, this time with two captial letters) and being told to stop.

(And I'm not sure about the majority communication pattern you tried to point
Steve at. I'm that >< close to put you into my killfile too.)

Everybody's entiled to his opinion but at some point, as Scott said, one has to
stop digging.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Bernd Zeimetz 
On 07/22/2012 01:24 AM, Steve McIntyre wrote:
> Lars Wirzenius wrote:
>>
>> In my opinion, _every_ technical committee decision should be posted
>> to debian-devel-announce. Any time that the TC needs to make a decision,
>> it's already an unusual circumstance, and usually something's gone wrong.
>> It's _good_ to inform the whole project about it. It is educational and
>> keeps the voting population informed.
> 
> Definitely, +1.

+2 :)


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500e5d26.7070...@bzed.de

Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Didier 'OdyX' Raboud 
Le mardi, 24 juillet 2012 09.03:30, Philipp Kern a écrit :
> On Mon, Jul 23, 2012 at 10:31:43PM -0400, Filipus Klutiero wrote:
> > Please try using complete sentences. While you're at it,
> > constructive messages would be more productive than name-calling.
> 
> If you think that your messages are constructive, well, you're wrong.
> You're repeating the same arguments over and over again, despite not being
> a Debian Developer (yes, this time with two captial letters) and being
> told to stop.

FWIW, although I agree with the uselessness of repeating arguments over and 
over, we should still be very careful about the use of the "You are no Debian 
Developer so you can't speak" argument: we have seen both useless and noisy 
contributions from DDs and useful and constructive contributions from non-DDs.

The DD status doesn't grant any right to behave as a troll; I tend to think it 
rather imposes the contrary.

Cheers,

OdyX


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

Re: glibc very old

2012-07-24 Thread Vincent Lefevre 
On 2012-07-24 13:45:08 +0900, Miles Bader wrote:
> Vincent Lefevre  writes:
> > By "correct", I mean that the result is somewhat acceptable (not
> > that the result is correctly rounded and the rounding direction is
> > honored), instead of getting completely wrong values or even a
> > crash.
> 
> But how often are directed rounding modes used?  Like 0.001% of the
> time?

They are not used often. However they must be correct.

> So... these functions were made almost an order of magnitude slower
> in the (overwhelmingly) common case, in order to handle rare and
> exceptional cases...?

This depends on the processor. You should get a processor that
handles rounding-mode change in a better way (the slowdown
should not be noticeable when you  just run the program, without
looking at the exact running time).

> I can see that as an emergency workaround when the deadline is next
> week, but it seems kind of questionable as a general technique.
> 
> Is there no more sane method?
> 
> E.g.:
> 
>  (1) have the FPU-twiddling functions ( stuff?) set a global
>  flag "FPU_is_twiddled = 1;"
> 
>  (2) write these rounding-mode-sensitive functions like:
> 
>if (FPU_is_twiddled)
>  return slow_ass_FPU_twiddling_version ();
>/* ... otherwise fall through to normal fast code ... */

There's only one code, which is run in both cases. The difference
is that the rounding mode is set to FE_TONEAREST at the beginning
of the function and restored at the end of the function.

The only sensible change that can be done (without requiring the
compiler a choice based on the FENV_ACCESS pragma) is to test a
global (actually TLS) flag as you propose so that the instruction
to control the rounding mode is not used if the processor was
already in FE_TONEAREST. But note that this could actually be
slower with some processors: the processor already knows the
rounding mode it is running under, so that if the rounding mode
is not changed, the rounding-mode control instruction should be
no slower than no-op!

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724090651.ga6...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

2012-07-24 Thread Vincent Lefevre 
On 2012-07-24 08:16:43 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre 
> 
> > On 2012-07-23 15:55:27 +0200, Tollef Fog Heen wrote:
> > > ]] Vincent Lefevre 
> > > 
> > > > On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> > > > > ]] Vincent Lefevre 
> > > > > 
> > > > > > OK, if Debian plans to support other init systems, that's fine.
> > > > > 
> > > > > It already does.
> > > > 
> > > > Not really, or at least not in a nice way, because sysvinit is
> > > > an essential package.
> > > 
> > > How is that relevant?  Don't we support pax just because tar is
> > > essential?
> > 
> > But installing pax won't remove tar, while...
> 
> I don't think it follows at all that because there are init systems
> which conflict with sysvinit, Debian does not support multiple init
> systems.

But in such a case, sysvinit shouldn't be an essential package (and
packages that need it should thus have an explicit dependency on it),
since it isn't really needed in a working Debian system. Otherwise,
if the user wants to use an init system that conflicts with sysvinit,
how do you know that he will not break his system (even if the new
init system is correctly configured)?

> > OK, the package description of systemd by mentioning the rcN.d links.
> > I had the impression they were still used.
> 
> They are, unless there are native service descriptions shipped.

If the package description had said that, it would have been
less confusing. It's strange for a package description to focus
on non-native features!

> > Also, it seems that to disable a daemon using systemd units, one needs
> > these native files. But many packages don't provide them. So, real
> > systemd support isn't really there.
> 
> You said «I don't see any init system that provides the same feature as
> ENABLE/DISABLE (i.e. together with other configuration options of the
> service, such as the port on which the daemon will listen).», you did
> not specify «without changing anything in the existing packages» og
> something similar.

Well, that was quite obvious to me. By init system support, I mean
that the init system should be provided as packages *and* that
packages providing a service should support the init system natively
(otherwise there isn't much point to switch to another init system).

> Also, to turn your argument on the head: many packages does not provide
> NO_START=1 in /etc/default, so real support for that isn't really there
> either.  On my system, it's about 8 of 103 init scripts, which is
> slightly higher than the ratio of packages shipping systemd service
> descriptions to packages shipping init scripts.  (58 / 1106 for .service
> files)

The only package for which I want to control whether the daemon is run
or not has such a switch (this is wicd-daemon). I don't (currently)
mind about the other packages. I just don't want this switch to
disappear, or wicd-daemon should provide a native systemd file to
start the daemon (which is not the case currently).

IMHO, for packages that provide such a switch, there should be no
requirement to abandon it without supporting the other init systems
first.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724093126.gb6...@ypig.lip.ens-lyon.fr

Re: solving the network-manager-in-gnome problem

2012-07-24 Thread Tollef Fog Heen 
]] Vincent Lefevre 

> But in such a case, sysvinit shouldn't be an essential package (and
> packages that need it should thus have an explicit dependency on it),
> since it isn't really needed in a working Debian system.

And people are working towards that goal.  We won't be there for wheezy,
but there is some progress in that direction.  Hopefully we'll be there
for wheezy+1.

> > They are, unless there are native service descriptions shipped.
> 
> If the package description had said that, it would have been
> less confusing. It's strange for a package description to focus
> on non-native features!

I don't know what you mean by non-native features.  Support for SysV
init scripts is native to systemd, but if there's both a sysvinit and a
.service file providing the same service, the .service file takes
precedence.  Similarly, if you have a .service file in
/lib/systemd/system and one in /etc/systemd/system, the latter takes
precedence.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eho14fqe@vuizook.err.no

Re: MATE Desktop Environment in Debian

2012-07-24 Thread Dmitry Shachnev 
I agree with Josselin here. There is no point in forking gconf and other
libraries. Even worse, this will increase the incompatibility between
different desktops. For example, an app making use of "gconftool-2" will
not work when there's "mateconftool-2" in the system instead.

If you want to fix a bug in GNOME libraries, you should propose a patch
to their bugzilla, they will be happy to accept it.

Also, we try to remove existing packages that use deprecated libraries
(like libgnome* and libbonobo*), and I think it's not good at all to add
new packages relying on those libraries.

--
Dmitry Shachnev
(Debian Maintainer)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1343127220.7568.5.camel@eeepc

Re: solving the network-manager-in-gnome problem

2012-07-24 Thread Roger Leigh 
On Tue, Jul 24, 2012 at 11:31:26AM +0200, Vincent Lefevre wrote:
> On 2012-07-24 08:16:43 +0200, Tollef Fog Heen wrote:
> > 
> > I don't think it follows at all that because there are init systems
> > which conflict with sysvinit, Debian does not support multiple init
> > systems.
> 
> But in such a case, sysvinit shouldn't be an essential package (and
> packages that need it should thus have an explicit dependency on it),
> since it isn't really needed in a working Debian system.

sysvinit will drop the essential status in wheezy+1.  Just lack of
time and testing the consequences prevented this being done already.


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724105617.gq25...@codelibre.net

Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Philipp Kern 
On Tue, Jul 24, 2012 at 10:36:51AM +0200, Didier 'OdyX' Raboud wrote:
> Le mardi, 24 juillet 2012 09.03:30, Philipp Kern a écrit :
> > On Mon, Jul 23, 2012 at 10:31:43PM -0400, Filipus Klutiero wrote:
> > > Please try using complete sentences. While you're at it,
> > > constructive messages would be more productive than name-calling.
> > If you think that your messages are constructive, well, you're wrong.
> > You're repeating the same arguments over and over again, despite not being
> > a Debian Developer (yes, this time with two captial letters) and being
> > told to stop.
> FWIW, although I agree with the uselessness of repeating arguments over and 
> over, we should still be very careful about the use of the "You are no Debian 
> Developer so you can't speak" argument: we have seen both useless and noisy 
> contributions from DDs and useful and constructive contributions from non-DDs.

Sure. I was refering to Steve's point about d-d-a being a list primarily
targetted at DDs and a must-subscribe for DDs. I just don't feel that some 
non-DD
can stand up and continue to demand changes that vocally if he's only a
circumstantial part of the audience. Especially given the fact that there was
no support for this cause from the target audience of the list.

And then he claimed to be a Debian developer[1] which is untrue given the
intended meaning DD.

Everybody can speak here as long as he contributes something useful[2].

> The DD status doesn't grant any right to behave as a troll; I tend to think 
> it 
> rather imposes the contrary.

Sure. I sort of realized that after sending my message that I should've said
that. Full ACK. :)

Kind regards
Philipp Kern

[1] The funny bit being that even the list page says "Debian developer" for
the people whose messages are accepted.
[2] Or funny, but that may be -curiosa material.


signature.asc
Description: Digital signature

Re: Bug#682496: ITP: melange -- Melange Widget System for the Cream Desktop Environment

2012-07-24 Thread Paul Tagliamonte 
On Tue, Jul 24, 2012 at 02:28:16PM +0800, Thomas Goirand wrote:
> On 07/24/2012 12:00 PM, Charles Plessy wrote:
> > Also, we should not favor software written in the context of our downstream
> > distributions, compared to sofware written independantly, otherwise the take
> > home message will be that if one project wants to own a dictionary word in
> > Debian, they just have to use it downstream first.
> >   
> At some point, projects have to decide for a name. I'm really not
> convinced that
> Melange is that generic. I'm not at all convinced either that someone is

 * Google's Melange
 * Melage (cream)
 * OpenStack Melange

> trying
> to do typo squatting either, just for the pleasure of owning dictionary
> words. It
> is just the way it is: Melange is there, and it's in Ubuntu. Denying
> that fact, and

No one's denying the fact -- I'm just saying, we can do the following
here:

 * No one takes `melange'
 * OpenStack Melange becomes openstack-melange (or whatever)
 * Cream becomes cream-melange (or whatever)
 * Ubuntu follows suit
 * Ubuntu MOTU / Core-dev upload `melange' as a transitional package
   which points to openstack-melange.

After this, they can wait 3 years if they want, then clear out the deps.

I mean, it's not that bad. Everyone here's seen worse. This would also
solve an annoying problem before we have to deal wit hit.

> that it might add difficulties in the future if we don't use the same
> names for
> the same thing will not help.
> 
> I'm only vouching for the least effort here. I really don't want to
> spend time
> convincing *both* upstream and Ubuntu guys that we shall rename. I'm not
> at all in the favor of having a special case for Debian either (which means
> that it would be more difficult to merge packaging efforts later).

I don't think my idea is significantly more work then yours :)

> 
> Thomas
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/500e4080.40...@debian.org
> 

Fondly,
 Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Bug#682661: ITP: powerdebug -- tool to display regulator, sensor and clock information

2012-07-24 Thread Marcin Juszkiewicz 
Package: wnpp
Severity: wishlist
Owner: Marcin Juszkiewicz 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: powerdebug
  Version : 0.6.1-2011.10
  Upstream Author : Linaro Power Management Working Group 

* URL : https://launchpad.net/linaro-powerdebug
* License : EPL-1.0
  Programming Lang: C
  Description : tool to display regulator, sensor and clock information

PowerDebug is a tool to display regulator, sensor and clock information.
Data is refreshed every few seconds. There is also dump option to display
the information just once.
..
Tool is mostly useful on non-x86 platforms.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlAOkMYACgkQeQ6MlGH/2qua/gCbB8Kd6RxAgFV97iYUsG8oYwxg
XVsAn2WPvKXtBRafaRn8t5/E/ejowrV2
=qw19
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724121049.19878.76418.reportbug@localhost6

Re: Bug#682496: ITP: melange -- Melange Widget System for the Cream Desktop Environment

2012-07-24 Thread Paul Tagliamonte 
Sorry for replying to myself, but here are some updates:

> 
> > that it might add difficulties in the future if we don't use the same
> > names for
> > the same thing will not help.
> > 

Ubuntu'e `melange' is Deprecated, and is pending removal from the
archive (see launchpad[1]).

It's deprecated upstream, and won't exist in Debian :)

Fondly,
 Paul


[1]: https://bugs.launchpad.net/ubuntu/+source/melange/+bug/1017609

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Processed (with 1 errors): Re: /usr/include/features.h referes to bits/predefs.h, but no "bits" link or dir in /usr/include

2012-07-24 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> # affects many libraries, not just libc
> reassign 682678 general
Bug #682678 [libc6-dev] /usr/include/features.h referes to bits/predefs.h, but 
no "bits" link or dir in /usr/include
Bug reassigned from package 'libc6-dev' to 'general'.
No longer marked as found in versions eglibc/2.13-33.
Ignoring request to alter fixed versions of bug #682678 to the same values 
previously set
> merge 637232 682678
Bug #637232 [general] general: Multiarch breaks support for non-multiarch 
toolchain
Bug #639214 [general] eglibc: changes to paths concerning crt1.o, crti.o and 
crtn.o breaks building LLVM Trunk
Bug #644986 [general] i386: Compiling gcc-snapshots from upstream with 
multiarch-toolchain?
Bug #648889 [general] /usr/include/features.h(323): catastrophic error: could 
not open source file "bits/predefs.h"
Unable to merge bugs because:
affects of #682678 is '' not 'release-notes,libc6-dev'
Failed to merge 637232: Did not alter merged bugs
Debbugs::Control::set_merged('transcript', 'GLOB(0x2df7c48)', 
'requester', 'Jonathan Nieder ', 'request_addr', 
'cont...@bugs.debian.org', 'request_msgid', 
'<20120724163848.GC2939@burratino>', 'request_subject', ...) called at 
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 537
eval {...} called at 
/usr/local/lib/site_perl/Debbugs/Control/Service.pm line 536
Debbugs::Control::Service::control_line('line', 'merge 637232 682678', 
'clonebugs', 'HASH(0x2d549e8)', 'limit', 'HASH(0x2d54430)', 
'common_control_options', 'ARRAY(0x2d54478)', 'errors', ...) called at 
/usr/lib/debbugs/service line 471

> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
637232: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637232
639214: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639214
644986: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644986
648889: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648889
682678: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682678
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.134314794020617.transcr...@bugs.debian.org

Processed: Re: /usr/include/features.h referes to bits/predefs.h, but no "bits" link or dir in /usr/include

2012-07-24 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> forcemerge 637232 682678
Bug #637232 [general] general: Multiarch breaks support for non-multiarch 
toolchain
Bug #639214 [general] eglibc: changes to paths concerning crt1.o, crti.o and 
crtn.o breaks building LLVM Trunk
Bug #644986 [general] i386: Compiling gcc-snapshots from upstream with 
multiarch-toolchain?
Bug #648889 [general] /usr/include/features.h(323): catastrophic error: could 
not open source file "bits/predefs.h"
Bug #682678 [general] /usr/include/features.h referes to bits/predefs.h, but no 
"bits" link or dir in /usr/include
Added indication that 682678 affects release-notes,libc6-dev
Bug #639214 [general] eglibc: changes to paths concerning crt1.o, crti.o and 
crtn.o breaks building LLVM Trunk
Bug #644986 [general] i386: Compiling gcc-snapshots from upstream with 
multiarch-toolchain?
Bug #648889 [general] /usr/include/features.h(323): catastrophic error: could 
not open source file "bits/predefs.h"
Merged 637232 639214 644986 648889 682678
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
637232: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637232
639214: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639214
644986: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644986
648889: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648889
682678: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682678
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.134314856224165.transcr...@bugs.debian.org

Bug#682692: ITP: tcl-fitstcl -- Tcl interface to FITS Files

2012-07-24 Thread Ole Streicher 
Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org

* Package name: tcl-fitstcl
  Version : 2.3
  Upstream Author : Have to ask - probably William Pence, Pan Chai
* URL :
http://heasarc.gsfc.nasa.gov/docs/software/lheasoft/ftools/fv/fitsTcl_home.html
* License : MIT
  Programming Lang: C
  Description : Tcl interface to FITS files

fitsTcl is an extension to the TCL language, providing simple access to
astronomical data stored in FITS file format. fitsTcl implements a TCL
interface to the CFITSIO library, developed by the HEASARC (High Energy
Astrophysics Science Archive Research Center) at the NASA Goddard Space
Flight Center.

This package is done in preparation of the "fv" package.

A git repository will be created on

http://anonscm.debian.org/gitweb/?p=debian-science/packages/tcl-fitstcl.git

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500edfaf.5050...@liska.ath.cx

Re: solving the network-manager-in-gnome problem

2012-07-24 Thread Vincent Lefevre 
On 2012-07-24 12:26:33 +0200, Tollef Fog Heen wrote:
> > If the package description had said that, it would have been
> > less confusing. It's strange for a package description to focus
> > on non-native features!
> 
> I don't know what you mean by non-native features.  Support for SysV
> init scripts is native to systemd, but if there's both a sysvinit and a
> .service file providing the same service, the .service file takes
> precedence.  Similarly, if you have a .service file in
> /lib/systemd/system and one in /etc/systemd/system, the latter takes
> precedence.

I just mean that the systemd package description mentions the SysV
init scripts, but not the .service files. So, it was not clear that
systemd had its own files that could replace the SysV init scripts
completely.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724180423.ga3...@ypig.lip.ens-lyon.fr

Bug#682706: ITP: crtools -- tools for freezing/checkpointing/restoring a running application

2012-07-24 Thread Artem Leshchev 
Package: wnpp
Severity: wishlist
Owner: Artem Leshchev 

* Package name: crtools
  Version : 0.1
  Upstream Author : OpenVZ Team 
* URL : http://criu.org/
* License : GPL
  Programming Lang: C, Assembler
  Description : tools for freezing/checkpointing/restoring a running 
application

Checkpoint/Restore In Userspace, or CRIU, is a tool, that can freeze a running
application (or part of it) and checkpoint it to a hard drive as a collection
of files. You can then use the files to restore and run the application from
the point it was frozen at. The distinctive feature of the CRIU project is that
it is mainly implemented in user space.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724194514.14720.21765.reportbug@localhost

Re: Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Filipus Klutiero 

Scott Kitterman wrote:

On Monday, July 23, 2012 11:00:37 PM Filipus Klutiero wrote:
>  Which kind of idiotic distraction?

The one where you continue this pointless thread.


I don't think this thread is pointless; it is simply too noisy.


   If it isn't clear to you
already let me try one more time: You've pretty thoroughly alienated the
people that'll decide how the tech ctte communicates it's decisions.


This certainly isn't "clear", and won't become so until things suggest 
that it is at least correct.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500f3875.4020...@gmail.com

Re: Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Filipus Klutiero 

Hi Russ,

Russ Allbery wrote:

Filipus Klutiero  writes:

>  The "second highest decision-making body" in question is also our lowest
>  conflict resolution body. I for one am not interested in reading the
>  outcome of each small claims case.

You have been heard.  I've read all of your messages on this thread, and
several other tech-ctte members have also read your request and the logic
behind it.  I also thought about your counter-arguments to some of my
reasons for wanting to post the decisions.

Several other people have also weighed in on their perception of the
usefulness of the communication.

I think there's enough information here to make a decision for right now.
> From the reactions of various people stated here, I think it's safe to say
that, for the time being, announcements of decisions to
debian-devel-announce will continue.  That's not because we've not
listened to your argument or gotten your point; it's just that other
people disagree.


I never intended to tell anyone that announcements of CTTE decisions to 
debian-devel-announce should stop. My message was only about this 
resolution. In fact, I hope that some further decisions will fit on 
d-d-a and be announced there.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500f39d1.5040...@gmail.com

Re: Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Filipus Klutiero 

Tollef Fog Heen wrote:

]] Filipus Klutiero

>  >  You are not a Debian developer.
>
>  I am.

You don't seem to be in LDAP, nor in the keyring, so no, you're not,
unless you're posting under some alias or similar.


I am posting under an alias, but in any case, Debian's LDAP and keyring 
only contain a fraction of developers.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500f3aa3.8030...@gmail.com

Re: Re: Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Filipus Klutiero 

Hi Philipp,

Philipp Kern wrote:

On Mon, Jul 23, 2012 at 10:31:43PM -0400, Filipus Klutiero wrote:
> Please try using complete sentences. While you're at it,
> constructive messages would be more productive than name-calling.

If you think that your messages are constructive, well, you're wrong. 
You're
repeating the same arguments over and over again, despite not being a 
Debian
Developer (yes, this time with two captial letters) and being told to 
stop.


If you think I'm repeating the same arguments over and over again, I 
would appreciate that you point to repetitions - once - rather than 
simply stating that you think I'm repeating myself without explanation.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500f3bda.4060...@gmail.com

Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Ulrich Dangel 
On 07/25/12 02:15, Filipus Klutiero wrote:

>> You don't seem to be in LDAP, nor in the keyring, so no, you're not,
>> unless you're posting under some alias or similar.
> 
> I am posting under an alias, but in any case, Debian's LDAP and keyring only
> contain a fraction of developers.

This is true for developers in general but we are talking about Debian 
Developers,
which are all present in the keyring as well as in the LDAP.

>From http://wiki.debian.org/DebianDeveloper:
A Debian developer (DD) is a Debian Project Member who has uploading rights.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/500f3c96.90...@spamt.net

Modified http://wiki.debian.org/DebianDeveloper to mention non-packagers (Re: [CTTE #614907] Resolution of node/nodejs conflict)

2012-07-24 Thread Charles Plessy 
Thread broken as topic changes.
In-Reply-To: <500f3c96.90...@spamt.net>

Le Wed, Jul 25, 2012 at 02:23:50AM +0200, Ulrich Dangel a écrit :
> 
> >From http://wiki.debian.org/DebianDeveloper:
> A Debian developer (DD) is a Debian Project Member who has uploading rights.

Hi Ulrich,

this page (and probably others) does not take into account that we have 
developers
who do not maintain packages.  I just changed it to:

A '''Debian developer''' (DD) is a [[DebianProjectMember|Debian Project
Member]] who has vote rights. Many maintain packages, but
[[http://www.debian.org/News/2010/20101019|other contributions]] are very
welcome as well.

It can probably be further enhanced.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120725004305.gf7...@falafel.plessy.net

Re: Modified http://wiki.debian.org/DebianDeveloper to mention non-packagers (Re: [CTTE #614907] Resolution of node/nodejs conflict)

2012-07-24 Thread Steve Langasek 
On Wed, Jul 25, 2012 at 09:43:05AM +0900, Charles Plessy wrote:
> Le Wed, Jul 25, 2012 at 02:23:50AM +0200, Ulrich Dangel a écrit :

> > >From http://wiki.debian.org/DebianDeveloper:
> > A Debian developer (DD) is a Debian Project Member who has uploading rights.

> this page (and probably others) does not take into account that we have 
> developers
> who do not maintain packages.  I just changed it to:

> A '''Debian developer''' (DD) is a [[DebianProjectMember|Debian Project
> Member]] who has vote rights. Many maintain packages, but
> [[http://www.debian.org/News/2010/20101019|other contributions]] are very
> welcome as well.

> It can probably be further enhanced.

Yes, as the new wording is logically inconsistent.  *By definition* a Debian
Project Member, as the term is being used here, is someone who has voting
rights.  The term "Debian Developer" was being used to distinguish between
project members who upload and those who do not.

I strongly recommend reverting to the previous text.

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bug#682706: ITP: crtools -- tools for freezing/checkpointing/restoring a running application

2012-07-24 Thread Yaroslav Halchenko 

On Tue, 24 Jul 2012, Artem Leshchev wrote:
> * Package name: crtools
>   >...<
> Checkpoint/Restore In Userspace, or CRIU, is a tool, that can freeze a running
> application (or part of it) and checkpoint it to a hard drive as a collection
> of files. You can then use the files to restore and run the application from
> the point it was frozen at. The distinctive feature of the CRIU project is 
> that
> it is mainly implemented in user space.

NB Kapil, would you be kind to clarify the relation/comparison?

i.e. like :

$> apt-cache show dmtcp
Package: dmtcp
Version: 1.2.5-1
Installed-Size: 1889
Maintainer: Kapil Arya 
Architecture: amd64
Depends: libmtcp1, libc6 (>= 2.9), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.2.1)
Description-en: Checkpoint/Restart functionality for Linux processes
 DMTCP (Distributed MultiThreaded Checkpointing) is a tool to transparently
 checkpointing the state of an arbitrary group of programs including
 multi-threaded and distributed computations.  It operates directly on the user
 binary executable, with no Linux kernel modules or other kernel mods.
 .
 Among the applications supported by DMTCP are OpenMPI, MATLAB, Python, Perl,
 and many programming languages and shell scripting languages.  DMTCP also
 supports GNU screen sessions, including vim/cscope and emacs. With the use of
 TightVNC, it can also checkpoint and restart X-Window applications, as long
 as they do not use extensions (e.g.: no OpenGL, no video).


-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120725021908.gm5...@onerussian.com

Re: Bug#682706: ITP: crtools -- tools for freezing/checkpointing/restoring a running application

2012-07-24 Thread Ben Hutchings 
On Tue, 2012-07-24 at 22:19 -0400, Yaroslav Halchenko wrote:
> On Tue, 24 Jul 2012, Artem Leshchev wrote:
> > * Package name: crtools
> >   >...<
> > Checkpoint/Restore In Userspace, or CRIU, is a tool, that can freeze a 
> > running
> > application (or part of it) and checkpoint it to a hard drive as a 
> > collection
> > of files. You can then use the files to restore and run the application from
> > the point it was frozen at. The distinctive feature of the CRIU project is 
> > that
> > it is mainly implemented in user space.
> 
> NB Kapil, would you be kind to clarify the relation/comparison?
> 
> i.e. like :
[...]

This one uses some new kernel facilities that allow checkpoint/restart
to be done reliably.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.


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

Re: Re: Re: Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Christian PERRIER 
Quoting Filipus Klutiero (chea...@gmail.com):

> >The purpose of debian-devel-announce is for communicating announcements *to
> >people involved with the development of Debian*.
> >
> >You are not a Debian developer.
> 
> I am.

Philippe, if you want to prove you're a DD, then sign you mails,
please.

I personnally appreciate the contributions you make in other fields of
Debian (particularly helping in reviewing the DPN) but, in this thread,
I don't really understand what point you're trying to make.




signature.asc
Description: Digital signature

Re: Bug#682706: ITP: crtools -- tools for freezing/checkpointing/restoring a running application

2012-07-24 Thread Carlos Alberto Lopez Perez 
On 25/07/12 04:19, Yaroslav Halchenko wrote:
> 
> On Tue, 24 Jul 2012, Artem Leshchev wrote:
>> * Package name: crtools
>>   >...<
>> Checkpoint/Restore In Userspace, or CRIU, is a tool, that can freeze a 
>> running
>> application (or part of it) and checkpoint it to a hard drive as a collection
>> of files. You can then use the files to restore and run the application from
>> the point it was frozen at. The distinctive feature of the CRIU project is 
>> that
>> it is mainly implemented in user space.
> 
> NB Kapil, would you be kind to clarify the relation/comparison?
> 

http://openvz.livejournal.com/42414.html



signature.asc
Description: OpenPGP digital signature

Re: [CTTE #614907] Resolution of node/nodejs conflict

2012-07-24 Thread Stephen Gran 
On Sat, Jul 21, 2012 at 04:35:10PM -0400, Filipus Klutiero said:
On Sat, Jul 21, 2012 at 04:38:21PM -0400, Filipus Klutiero said:
On Sat, Jul 21, 2012 at 04:42:06PM -0400, Filipus Klutiero said:
On Sat, Jul 21, 2012 at 04:49:07PM -0400, Filipus Klutiero said:
On Sat, Jul 21, 2012 at 04:52:51PM -0400, Filipus Klutiero said:
On Sun, Jul 22, 2012 at 07:33:37PM -0400, Filipus Klutiero said:
On Sun, Jul 22, 2012 at 07:37:23PM -0400, Filipus Klutiero said:
On Sun, Jul 22, 2012 at 07:49:50PM -0400, Filipus Klutiero said:
On Sun, Jul 22, 2012 at 07:54:26PM -0400, Filipus Klutiero said:
On Mon, Jul 23, 2012 at 10:31:43PM -0400, Filipus Klutiero said:
On Mon, Jul 23, 2012 at 10:37:48PM -0400, Filipus Klutiero said:
On Mon, Jul 23, 2012 at 11:00:37PM -0400, Filipus Klutiero said:
On Tue, Jul 24, 2012 at 08:06:13PM -0400, Filipus Klutiero said:
On Tue, Jul 24, 2012 at 08:12:01PM -0400, Filipus Klutiero said:
On Tue, Jul 24, 2012 at 08:20:42PM -0400, Filipus Klutiero said:
> If you think I'm repeating the same arguments over and over again

Can someone please make this stop now?

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Modified http://wiki.debian.org/DebianDeveloper to mention non-packagers (Re: [CTTE #614907] Resolution of node/nodejs conflict)

2012-07-24 Thread Lars Wirzenius 
On Tue, Jul 24, 2012 at 06:00:21PM -0700, Steve Langasek wrote:
> Yes, as the new wording is logically inconsistent.  *By definition* a Debian
> Project Member, as the term is being used here, is someone who has voting
> rights.  The term "Debian Developer" was being used to distinguish between
> project members who upload and those who do not.

I'm not convinced there's consensus on that terminology. Our constitution does
not talk about project members, and instead uses the word "developer". It would
be really good if we could avoid a terminology ambiguity proliferation about 
this.

-- 
I wrote a book on personal productivity: http://gtdfh.branchable.com/


signature.asc
Description: Digital signature