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

[Lars Wirzenius]

On Sun, Jul 22, 2012 at 07:49:50PM -0400, Filipus Klutiero wrote:
> Hi Lars,
> 
> Lars Wirzenius wrote:
> 
> >On Sat, Jul 21, 2012 at 04:38:21PM -0400, Filipus Klutiero wrote:
> >>  Hi Stefano,
> >>
> >>  Stefano Zacchiroli wrote:
> >>  >On Tue, Jul 17, 2012 at 08:07:15PM -0400, Filipus Klutiero wrote:
> >>  >>   Thank you, but I would appreciate if debian-devel-announce would
> >>  >>   stay dedicated to important announcements which may be useful for a
> >>  >>   wide range of developers.
> >>  >
> >>  >tech-ctte resolutions do fit that bill. The tech-ctte is the highest
> >>  >dispute resolution body we have in Debian, and I think their doings
> >>  >deserve this level of awareness in the project.
> >>
> >>  although publicity of some resolutions may indeed be useful for a
> >>  wide range of developers, I fail to see many who would be interested
> >>  in the resolution on node.
> >
> >You're complaining about the posting volume of a list that has 13 +
> >17 + 16 + 7 + 8 + 10 + 4 = 75 messages this year, or about 2.6 days
> >between posts.
> 
> No, I simply explained it would have been better to send the message
> in question elsewhere, avoiding debian-devel-announce.

I stand by my claim.

 It may be
> that there are few messages in this situation, and that more
> messages were in the opposite situation and should have been sent to
> debian-devel-announce.
> >[...]
> >
> >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.
> 
> Conflicts are intrinsic in projects divided into thousands of
> inter-dependent sub-projects with private decision-making
> processes... I would be more worried to see no conflicts in our
> system.

Yes, conflicts certainly are inevitable. When they escalate to the second
highest decision-making body in the project, which makes a decision,
that is clearly important enough that it warrants an announcement to
the entire membership of the Debian project.

Although the Technical Committee is not a judge, an analogy with the
legal system may make things clearer: the press does not announce every
decision made by every judge in a court of law, but it does do so for
every decision made by the supreme court, whether the case as such is of
general interest or not. This is important so that the general population
can keep an eye on those in power. It's also important so we know what's
going on and can learn. It does not matter if it generates a small amount
of extra items in the newspaper, since the total volume of supreme court
decisions is quite low.

Like Steve and Steve, I'm not going to debate this further with you.
I'm not going to killfile you, but I suggest you find ways in which you
can help Debian development in constructive ways, rather than this kind
of idiotic distraction. So far, I admit I don't see you as a helpful
part of the Debian development community, and I wish you would rectify
the situation: preferably by starting to do things, but otherwise by
leaving.

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


signature.asc
Description: Digital signature

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

[Tollef Fog Heen]

]] Vincent Lefevre 

> OK, if Debian plans to support other init systems, that's fine.

It already does.

-- 
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/87hasy6g7j@vuizook.err.no

Bug#637232: Multiarch breaks support for non-multiarch toolchain

[Goswin von Brederlow]

On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote:
> affects 637232 + release-notes
> quit
> 
> Hi,
> 
> Matthias Klose wrote:
> > On 08/09/2011 07:31 PM, Aurelien Jarno wrote:
> 
> >> I got fed up by people reporting bug on libc6, while this problem results
> >> from a decision Debian to implement multiarch. People should work on
> >> implementing a compatibility wrapper and to make upstream toolchain
> >> multiarch aware. Until this is done, this bug should be kept opened.
> >
> > just do it.
> 
> To be realistic, is anyone actually going to do this?
> 
> Avenues forward:
> 
>  a) Help upstream authors of toolchain components with hardcoded
> header and library search paths to implement multiarch.
> 
>   gcc: in progress - http://gcc.gnu.org/PR53468 (thanks, Matthias!)
>   clang: fixed? - http://llvm.org/bugs/show_bug.cgi?id=6541
>   icc (Intel C++): status?
>   pathcc (PathScale ekopath): status?
>   tcc (Tiny C compiler): fixed - b56edc7b, 2012-05-22
>   pcc (Portable C compiler): unfixed - http://bugs.debian.org/638309
>   cmake: fixed - http://public.kitware.com/Bug/view.php?id=12037

What I don't understand is why compilers (which probably means ld from
binutils in all cases) won't use ld.so.conf to find the libs. It only
does so to find libs linked into libs you link against. So it is used
execpt for the verry first level of recursion. Maybe this could be fixed
better in a single common point.

>  b) There is a workaround described in libc6/NEWS.Debian.gz which
> works fine:
> 
>   LIBRARY_PATH=/usr/lib/
>   CPATH=/usr/include/
>   export CPATH LIBRARY_PATH
> 
> It's probably worth advertising that more widely, for example in
> the release notes.

I find it a bit hard to believe CPATH is needed. That directory has
been in use for years and years way before multiarch. Anyone know
which compiler needs it?

>  c) Compatibility wrapper.  If someone needs this, feel free to email
> me and I'll help out however I can.

If you write one of those then please make sure it works with gcc, gcc
-m32, gcc -m64 and uclibc (which brings some wrappers already I
believe). It would also be nice to include i486-linux-gnu-* on amd64
and amd64-linux-gnu-* on i386 and similar for other archs.

MfG
Goswin


-- 
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/20120723083604.GA10263@frosties

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

[Antti-Juhani Kaijanaho]

On Mon, Jul 23, 2012 at 09:08:25AM +0100, Lars Wirzenius wrote:
> Yes, conflicts certainly are inevitable. When they escalate to the second
> highest decision-making body in the project, which makes a decision,
> that is clearly important enough that it warrants an announcement to
> the entire membership of the Debian project.

I agree.

> an analogy with the legal system may make things clearer: the press does not
> announce every decision made by every judge in a court of law, but it does do
> so for every decision made by the supreme court, whether the case as such is
> of general interest or not.

I doubt that's true, though (unless one includes specialized press such as
SCOTUSblog in the US).  In any case, the analogy is faulty: it's not like the
Supreme Court buys advertisements (or compels publication of stories about its
decisions) - it just puts the decisions out there where journalists can see
them and allows them to pick and choose stories that would interest their
readers.

The main reason I think the TC should continue posting their decisions to d-d-a
is that their decisions are exceptions to the usual Debian decisionmaking.
Each one of them should evoke a sense of shock - why didn't the usual processes
work in this case?[*] - and they cannot do that if they are not widely
published.  A policy of posting all such decisions to d-d-a also gives the
developers a sense of how frequent such exceptional cases are and serves as a
crude measure of project health.  Even a conspicuous absence of such postings
would be significant, as it's a bit like a body temperature: too hot is a sign
of illness, but too cold also signifies that something's not right (usually the
thermometer has broken down).

There's also the aspect of oversight by the developers by way of general
resolution, but I think that is a minor issue.  If the TC makes such a bad
decision that it warrants reversal by GR, the developers who were party to the
dispute are quite able to make the case known even if the TC's decisions
weren't widely known in general.  (As a matter of personal policy, I would vote
to affirm the TC's judgment even if I disagreed with it, unless it's grossly
irregular or grossly broken.)


[*] In the past, when I wasn't lurking on the -ctte mailing list, each decision
I became aware was indeed a shock to me, and I went to the archives to see what
had happened.  Now I watch the horrors live :-)

> the total volume of supreme court decisions is quite low.

Not quite.  Although the US Supreme Court issues less than a hundred merits
decisions a year, they make a lot more summary decisions (mainly denial of
certiorari - they exercise their discretion not to hear a case) each year, most
of which even the courtwatcher press does not note.  The numbers are similar, I
believe, for the Finnish Supreme Court.

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/



signature.asc
Description: Digital signature

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

[Didier 'OdyX' Raboud]

Le mercredi, 18 juillet 2012 13.04:36, Wookey a écrit :
> I don't use n-m because it doesn't play nice with usb0 gadget
> networking.

I have read this claim multiple times now and it got me confused: on a wheezy 
laptop with network-manager and KDE, I can connect my Android phone trough USB 
and get internet access trough it just fine; it just works™.

Where's the issue ? When this USB connection shouldn't be used as "the uplink 
connection" ?

Cheers,

OdyX


--
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/201207231219.26605.o...@debian.org

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

[Henrique de Moraes Holschuh]

On Mon, 23 Jul 2012, Vincent Lefevre wrote:
> so that if you want to make things more consistent, you should
> get rid of /etc/default entirely.

/etc/default is used for a lot more than just enabling/disabling services,
and it will not go away.

Now, if you just mean removing enable/disable switches for initscripts from
/etc/default/*, that should be doable with some effort.  And that's what
this subthread is about.

> to my own working copy. Now I could do that. Then Subversion won't
> detect by itself files that have been added or removed. I need to tell
> it explicitly, which is annoying, as this isn't done automatically.
> But the main problem is the history. If there's only one file, I can
> do, e.g. "svn log the_file". But if files (symlinks) are added or
> removed, I can no longer get the log. Or I need to do that on the

Use the right tool for the job.  SVN is crap for this particular use case,
and any difficulties involving the use of svn to track /etc are irrelevant
because it simply cannot be expected to work properly anyway.  Switch to
etckeeper + git or something else that can version-control symlinks, owner
and mode changes in an useful way (git itself is not enough, thus the use of
etckeeper on top of git).

And that has nothing to do with the interesting part, which is to remove
enable/disable switches for initscripts from /etc/default.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120723102340.ga9...@khazad-dum.debian.net

Bug#682487: ITP: python-javascriptcore -- Python API for WebKit

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: python-javascriptcore
  Version : 0.1
  Upstream Author : Martin Soto 
* URL : https://launchpad.net/pyjavascriptcore
* License : LGPL-2.1+
  Programming Lang: Python
  Description : Python API for WebKit

Use Python to tap into the whole power of WebKit.

The packaging will take place in context of packaging the Cream Desktop 
Environment.


-- 
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/20120723105350.16900.67281.report...@minobo.das-netzwerkteam.de

Bug#682488: ITP: python-xmlserialize -- Python-(to|from)-xml-(un)serializer

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: python-xmlserialize
  Version : 1.0
  Upstream Author : Jonas Haag 
* URL : https://github.com/jonashaag/xmlserialize.py
* License : BSD-2-clause
  Programming Lang: Python, etc.
  Description : Python-(to|from)-xml-(un)serializer

An extensible Python-(to|from)-xml-(un)serializer in beautiful pure-Python
code.

The packaging takes place in context of packaging the Cream Desktop Environment.


-- 
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/20120723104252.14783.22073.report...@minobo.das-netzwerkteam.de

Bug#682489: ITP: python-gpyconf -- Python configuration framework with support for multiple backends

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: python-gpyconf
  Version : 0.2~beta
  Upstream Author : Jonas Haag 
* URL : https://github.com/jonashaag/gpyconf
* License : LGPL-2.1 and/or BSD-2-clause (modified)
  Programming Lang: Python
  Description : Python configuration framework with support for multiple 
backends

A modular Python configuration framework with support for multiple backends
(ConfigParser, XML, JSON, ...) and multiple frontends (GTK+, Web, ...).

The packaging takes place in context of packaging the Cream Desktop Environment.


-- 
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/20120723104720.16107.58905.report...@minobo.das-netzwerkteam.de

Bug#682491: ITP: python-ooxcb -- X Python Binding based on xpyb

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: python-ooxcb
  Version : 1.2
  Upstream Author : Friedrich Weber 
* URL : http://git.samurai-x.org/ooxcb/, 
git://git.samurai-x.org/ooxcb.git
* License : BSD-3-clause
  Programming Lang: Python
  Description : X Python Binding based on xpyb

An object-oriented X Python Binding, based on xpyb.

More information on the project can be obtained from this ML post:
http://lists.freedesktop.org/archives/xcb/2011-May/007030.html

The packaging takes place in context of packaging the Cream Desktop Environment.


-- 
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/20120723110825.18244.31274.report...@minobo.das-netzwerkteam.de

Bug#682492: ITP: python-bjoern -- Fast And Ultra-Lightweight Asynchronous HTTP/1.1 WSGI Server

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: python-bjoern
  Version : 1.2
  Upstream Author : Jonas Haag 
* URL : https://github.com/jonashaag/bjoern
* License : BSD-2-clause
  Programming Lang: Python
  Description : Fast And Ultra-Lightweight Asynchronous HTTP/1.1 WSGI Server

A screamingly fast, ultra-lightweight asynchronous WSGI server for CPython,
written in C using Marc Lehmann's high performance libev event loop and
Ryan Dahl's http-parser.

The packaging takes place in context of packaging the Cream Desktop Environment.


-- 
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/20120723111247.20224.81761.report...@minobo.das-netzwerkteam.de

Bug#682495: ITP: python-cream -- Python modules for the Cream Desktop

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: python-cream
  Version : 0.4.2
  Upstream Author : Sebastian Billaudelle 
* URL : http://cream-project.org
* License : LGPL-2.1+
  Programming Lang: Python
  Description : Python modules for the Cream Desktop Environment

The Cream Desktop Environment is a project working on a GTK+-based Desktop
Environment providing users a working environment following the KISS principle.
.
Your desktop shell should stay out of your way and support you in accomplishing
your everyday tasks. But unlike several other great projects, the Cream Desktop
Environment also focusses on a modern graphics design and a rich user
experience based on latest technologies.
.
This package contains basic Python modules for the Cream Desktop Environment.


-- 
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/20120723112710.22505.86025.report...@minobo.das-netzwerkteam.de

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

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: melange
  Version : 0.4.9
  Upstream Author : Sebastian Billaudelle 
* URL : http://cream-project.org
* License : LGPL-2.1+
  Programming Lang: Python
  Description : Melange Widget System for the Cream Desktop Environment

The Melange widget system provides an easy to use API for creating widgets
for the Cream Desktop Environment. Creating Melange widgets is very simple.
.
Basically Melange widgets are simple HTML pages and you do not have to know
GTK+ in order to write nice widgets. You can use everything HTML offers you,
including new HTML5 features such as the canvas element. Furthermore CSS and
Javascript can be used to extend the HTML.
.
As if that isn’t enough you can use Python to collect and process data, which
then can be used in your widget.


--
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/20120723113109.23448.43981.report...@minobo.das-netzwerkteam.de

Bug#682500: ITP: melange-widgets -- Melange widget collection for the Cream Desktop Environment

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: melange-widgets
  Version : 0.4.8
  Upstream Author : Sebastian Billaudelle 
* URL : http://cream-project.org
* License : LGPL-2.1+
  Programming Lang: Python
  Description : Melange widget collection for the Cream Desktop Environment

The Melange widget system provides an easy to use API for creating widgets
for the Cream Desktop Environment. Creating Melange widgets is very simple.
.
This package contains collection of basic/exemplary widgets for Melange.


-- 
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/20120723113657.24181.65373.report...@minobo.das-netzwerkteam.de

Bug#682502: ITP: console -- Terminal application for the Cream Desktop Environment

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: console
  Version : 0.0.9
  Upstream Author : Sebastian Billaudelle 
* URL : http://cream-project.org
* License : GPL-2+
  Programming Lang: Python
  Description : Terminal application for the Cream Desktop Environment

The Cream Desktop Environment is a project working on a GTK+-based Desktop
Environment providing users a working environment following the KISS principle.
.
Your desktop shell should stay out of your way and support you in accomplishing
your everyday tasks. But unlike several other great projects, the Cream Desktop
Environment also focusses on a modern graphics design and a rich user
experience based on latest technologies.
.
This package contains a terminal application for the Cream Desktop Environment.


-- 
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/20120723114048.24968.21819.report...@minobo.das-netzwerkteam.de

Bug#682503: ITP: cream-hotkey-manager -- Managing global hotkeys with the Cream Desktop Environment

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: cream-hotkey-manager
  Version : 0.1.1
  Upstream Author : Sebastian Billaudelle 
* URL : http://cream-project.org
* License : GPL-2+
  Programming Lang: Python
  Description : Managing global hotkeys with the Cream Desktop Environment

The Cream Desktop Environment is a project working on a GTK+-based Desktop
Environment providing users a working environment following the KISS principle.
.
Your desktop shell should stay out of your way and support you in accomplishing
your everyday tasks. But unlike several other great projects, the Cream Desktop
Environment also focusses on a modern graphics design and a rich user
experience based on latest technologies.
.
This package contains the Cream Desktop's global hotkey manager.


-- 
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/20120723114419.25639.346.report...@minobo.das-netzwerkteam.de

Bug#637232: Multiarch breaks support for non-multiarch toolchain

[Jonathan Nieder]

Hi,

Goswin von Brederlow wrote:
> On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote:

>>  a) Help upstream authors of toolchain components with hardcoded
>> header and library search paths to implement multiarch.
[...]
> What I don't understand is why compilers (which probably means ld from
> binutils in all cases) won't use ld.so.conf to find the libs. It only
> does so to find libs linked into libs you link against. So it is used
> execpt for the verry first level of recursion.

The ld library path and compiler library path represent different
things[*].

[..]
>Maybe this could be fixed
> better in a single common point.

Something like "getconf CPATH" and "getconf LIBRARY_PATH" producing
approprite lists for passing to -I and -L to find the system libs and
headers without having to parse "gcc -print-search-dirs" output could
be interesting.  Is that what you mean?

[...]
> I find it a bit hard to believe CPATH is needed. That directory has
> been in use for years and years way before multiarch.

>From the bug log:

| Bug#637218 is a similar problem about headers moving.

Have you tried it and run into different results?

>>  c) Compatibility wrapper.  If someone needs this, feel free to email
>> me and I'll help out however I can.
>
> If you write one of those then please make sure it works with gcc, gcc
> -m32, gcc -m64 and uclibc
[...]

Let's not get ahead of ourselves.  I'm not aware of a wrapper having
been written, and I certainly wouldn't want to impose additional
requirements on someone trying unless someone interested is providing
the patches to support those.

Hope that helps,
Jonathan

[*]
- One is looking for libfoo.so.5, the other for libfoo.so and
  libfoo.a.
- One points to libs on the arch with running binaries, while the
  other has libs for the cross-compilation target.
- One contains /lib, the other doesn't.
- One should not contain compiler-specific directories like
  /usr/lib/gcc/i486-linux-gnu/4.6, while the other does.
- One can be manipulated for special-case tricks with LD_LIBRARY_PATH,
  the other with LIBRARY_PATH.

Declaring that the compiler library path always include the ld library
path would not take care of cross-compilation anyway, so my first
reaction is to suspect it wouldn't be worth the side-effects.


-- 
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/20120723114458.GC14294@burratino

Bug#682505: ITP: cream-pim -- Personal Information Manager for the Cream Desktop Environment

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: cream-pim
  Version : 0.4
  Upstream Author : Sebastian Billaudelle 
* URL : http://cream-project.org
* License : LGPL-2.1+
  Programming Lang: Python
  Description : Personal Information Manager for the Cream Desktop 
Environment

The Cream Desktop Environment is a project working on a GTK+-based Desktop
Environment providing users a working environment following the KISS principle.
.
Your desktop shell should stay out of your way and support you in accomplishing
your everyday tasks. But unlike several other great projects, the Cream Desktop
Environment also focusses on a modern graphics design and a rich user
experience based on latest technologies.
.
This package contains the Cream Desktop's personal information manager.


-- 
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/20120723114750.26165.71617.report...@minobo.das-netzwerkteam.de

Re: Bug#637232: Multiarch breaks support for non-multiarch toolchain

[Ivan Shmakov]

> Jonathan Nieder  writes:
> Goswin von Brederlow wrote:

 >> What I don't understand is why compilers (which probably means ld
 >> from binutils in all cases) won't use ld.so.conf to find the libs.
 >> It only does so to find libs linked into libs you link against.  So
 >> it is used execpt for the verry first level of recursion.

 > The ld library path and compiler library path represent different
 > things[*].

Somehow, I guess that “the ld.so(8) library path” and “the ld(1)
library path” were actually meant here.

[…]

-- 
FSF associate member #7257  http://sf-day.org/


-- 
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/86pq7my9i5@gray.siamics.net

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

[Neil Williams]

On Mon, 23 Jul 2012 13:31:09 +0200
Mike Gabriel  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Mike Gabriel 
> 
> * Package name: melange

What, if any, is the relationship between this and melange used for the
Google Summer of Code?

http://code.google.com/p/soc/

Maybe cream-melange for clarity?

>   Version : 0.4.9
>   Upstream Author : Sebastian Billaudelle 
> * URL : http://cream-project.org
> * License : LGPL-2.1+
>   Programming Lang: Python
>   Description : Melange Widget System for the Cream Desktop Environment
> 
> The Melange widget system provides an easy to use API for creating widgets
> for the Cream Desktop Environment. Creating Melange widgets is very simple.


-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp0bAmAdmISo.pgp
Description: PGP signature

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

[Charles Plessy]

Le Mon, Jul 23, 2012 at 01:31:09PM +0200, Mike Gabriel a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Mike Gabriel 
> 
> * Package name: melange
> * Package name: console

Dear Mike,

I am a bit concerned that these are quite common words.  Have you considered
calling the packages cream-melange and cream-console instead ?  At the
begining, I thought you were packaging Google's Melange application...

Have a nice day,

-- 
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/20120723120139.gd20...@falafel.plessy.net

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

[Mike Gabriel]

retitle #682496 ITP: cream-melange -- Melange Widget System for the Cream 
Desktop Environment
thanks

Hi Neil et al.

Am Montag, 23. Juli 2012, 14:01:01 schrieb Neil Williams:
> On Mon, 23 Jul 2012 13:31:09 +0200
> 
> Mike Gabriel  wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Mike Gabriel 
> > 
> > * Package name: melange
> 
> What, if any, is the relationship between this and melange used for the
> Google Summer of Code?
> 
> http://code.google.com/p/soc/
> 
> Maybe cream-melange for clarity?
> 
> >   Version : 0.4.9
> >   Upstream Author : Sebastian Billaudelle 
> > 
> > * URL : http://cream-project.org
> > * License : LGPL-2.1+
> > 
> >   Programming Lang: Python
> >   Description : Melange Widget System for the Cream Desktop
> >   Environment
> > 
> > The Melange widget system provides an easy to use API for creating
> > widgets for the Cream Desktop Environment. Creating Melange widgets is
> > very simple.

ACK!

Thanks for your feedback,
Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0x1943CA5B
mail: m.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


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

Re: Bug#682500: ITP: melange-widgets -- Melange widget collection for the Cream Desktop Environment

[Mike Gabriel]

retitle #682500 ITP: cream-melange-widgets -- Melange widget collection for the 
Cream Desktop Environment
thanks

Hi all,

Am Montag, 23. Juli 2012, 13:36:57 schrieb Mike Gabriel:
> Package: wnpp
> Severity: wishlist
> Owner: Mike Gabriel 
> 
> * Package name: melange-widgets
>   Version : 0.4.8
>   Upstream Author : Sebastian Billaudelle 
> * URL : http://cream-project.org
> * License : LGPL-2.1+
>   Programming Lang: Python
>   Description : Melange widget collection for the Cream Desktop
> Environment
> 
> The Melange widget system provides an easy to use API for creating widgets
> for the Cream Desktop Environment. Creating Melange widgets is very simple.
> .
> This package contains collection of basic/exemplary widgets for Melange.

along with renaming ITP for melange -> cream-melange, I rename melange-widgets 
to cream-melange-widgets.

Cheers,
Mike


-- 

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0x1943CA5B
mail: m.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


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

Re: Bug#682502: ITP: console -- Terminal application for the Cream Desktop Environment

[Mike Gabriel]

Hi again,

On Mo 23 Jul 2012 13:58:05 CEST Neil Williams wrote:


On Mon, 23 Jul 2012 13:40:48 +0200
Mike Gabriel  wrote:


Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: console


That's too generic. cream-console would be better. Or, to fit in with
other terminal packages, cream-terminal.


  Description : Terminal application for the Cream Desktop Environment


It would probably make sense to rename the console executable (as  
provided by upstream) to cream-terminal then? Or will Debian accept an  
binary with the name of console in /usr/bin?


Thanks+Greets,
Mike

--

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpVU2MivOpzR.pgp
Description: Digitale PGP-Unterschrift

Re: Bug#682502: ITP: console -- Terminal application for the Cream Desktop Environment

[Andrey Rahmatullin]

On Mon, Jul 23, 2012 at 02:29:23PM +0200, Mike Gabriel wrote:
> It would probably make sense to rename the console executable (as
> provided by upstream) to cream-terminal then?
Of course (and poke upstream to do that, not just rename it in the
package).

> Or will Debian accept an binary with the name of console in /usr/bin?
I was going to answer "of course no" but then I've found /usr/bin/console
in conserver-client package. That's a bad idea anyway.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: glibc very old

[Vincent Lefevre]

On 2012-07-23 14:49:35 +0900, Miles Bader wrote:
> Based on a glance at the source, it seems like the math libraries were
> changed in lots of little ways between 2.13 and 2.16 [and it looks
> like the FPU-twiddling that made expf slow in 2.13 has been _added_ to
> the generic version of the "exp" (double-precision) function, meaning
> it might actually be (much) _slower_ in 2.16 on ports without
> optimized implementations... :( ]

However (if this is the change I'm thinking of) this makes math functions
"correct" in directed rounding modes and potentially more secure.

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.

-- 
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/20120723123534.ga9...@ypig.lip.ens-lyon.fr

Re: Bug#682502: ITP: cream-terminal -- Terminal application for the Cream Desktop Environment (was: Bug#682502: ITP: console -- Terminal application for the Cream Desktop Environment)

[Mike Gabriel]

Hi Andrey et al.

On Mo 23 Jul 2012 14:34:58 CEST Andrey Rahmatullin wrote:


On Mon, Jul 23, 2012 at 02:29:23PM +0200, Mike Gabriel wrote:

It would probably make sense to rename the console executable (as
provided by upstream) to cream-terminal then?

Of course (and poke upstream to do that, not just rename it in the
package).


Or will Debian accept an binary with the name of console in /usr/bin?

I was going to answer "of course no" but then I've found /usr/bin/console
in conserver-client package. That's a bad idea anyway.


The package has been retitled to ,,cream-terminal'' (I might have  
forgotten to Cc: d-d ML for that, sorry), I encourage upstream to  
rename the binary (and maybe the upstream project), as well.


OT: Same with melange -> cream-melange (though melange as binary name  
is not in use...).


Greets,
Mike


--

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpVw1YN67daD.pgp
Description: Digitale PGP-Unterschrift

Re: mark 'editor' virtual package name as obsolete

[Ian Jackson]

Artem Leschev writes ("mark 'editor' virtual package name as obsolete"):
> Virtual package name 'editor' was removed from Authoritative List of
> Virtual Package Names in 1996 year, but it is used at our days. Maybe we
> need to add it to section "Old and obsolete virtual package names",
> which is empty? If yes, we need to file a bug against each package that
> uses it, so this name will be removed from repository. If no, maybe we
> need to add it again in the List?
> I've filed a bug about this on [1].
> 
> [1] 

Of course these kind of leftover wrinkles do little harm.  And in the
case of things removed more recently, they can do some good.  Users
and our derivatives may want to mix old and new versions of packages.

Often that's hard to support well, and I certainly wouldn't say that
we should regard it as a bug (even a valid wishlist bug) if (say) foo
from wheezy doesn't work with bar from etch.  But on the other hand
going around removing compatibility code is something we should only
do when the last user vanished from our own sight a very long time ago
- since our sight is limited.

In this case I haven't checked to see what bits of our own archive
stopped using the virtual package `editor' when.  If indeed uses of it
were eliminated a decade ago the clearly it's fine to remove it.

Ian.


-- 
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/20493.19292.132893.915...@chiark.greenend.org.uk

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

[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. Also, 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).

-- 
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/20120723131006.gb9...@ypig.lip.ens-lyon.fr

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

[Vincent Lefevre]

On 2012-07-23 07:23:40 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 23 Jul 2012, Vincent Lefevre wrote:
> > so that if you want to make things more consistent, you should
> > get rid of /etc/default entirely.
> 
> /etc/default is used for a lot more than just enabling/disabling services,
> and it will not go away.

But with /etc/default, you can override options. For instance,
for sshd, the port can be provided either in /etc/ssh/sshd_config
or in /etc/default/ssh.

> Now, if you just mean removing enable/disable switches for initscripts from
> /etc/default/*, that should be doable with some effort.  And that's what
> this subthread is about.

No, I just mean that configuration of some service should be
in a limited number of places. But if you agree that it's fine
for /etc/default to override config setup somewhere else, then
there should not be any problem with ENABLE/DISABLE.

> > to my own working copy. Now I could do that. Then Subversion won't
> > detect by itself files that have been added or removed. I need to tell
> > it explicitly, which is annoying, as this isn't done automatically.
> > But the main problem is the history. If there's only one file, I can
> > do, e.g. "svn log the_file". But if files (symlinks) are added or
> > removed, I can no longer get the log. Or I need to do that on the
> 
> Use the right tool for the job.  SVN is crap for this particular use case,
> and any difficulties involving the use of svn to track /etc are irrelevant
> because it simply cannot be expected to work properly anyway.  Switch to
> etckeeper + git or something else that can version-control symlinks, owner
> and mode changes in an useful way (git itself is not enough, thus the use of
> etckeeper on top of git).

etckeeper is not the right tool because it will store private data
(e.g. passwords and private keys). I want to track only public data
and only files for which I have done a local modification.

-- 
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/20120723132629.gc9...@ypig.lip.ens-lyon.fr

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

[Vincent Lefevre]

On 2012-07-23 15:26:29 +0200, Vincent Lefevre wrote:
> No, I just mean that configuration of some service should be
> in a limited number of places. But if you agree that it's fine
> for /etc/default to override config setup somewhere else, then
> there should not be any problem with ENABLE/DISABLE.

And something else that can be done via /etc/default is that one
can write comments (e.g. "Temporarily disabled because of bug..."),
something that cannot be done with "update-rc.d".

-- 
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/20120723133633.ga11...@ypig.lip.ens-lyon.fr

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

[Tollef Fog Heen]

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

> Also, 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 might want to look again, then, there are multiple ways to disable a
daemon using systemd units.

-- 
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/874noyfupc@xoog.err.no

Re: AArch64 planning BoF at DebConf

[Steve McIntyre]

On Sat, Jul 21, 2012 at 07:47:01AM +0100, Lars Wirzenius wrote:
>On Sat, Jul 21, 2012 at 02:12:41AM +0100, Wookey wrote:
>> tools POV). The one _good_ reason for using the aarch64 name is avoiding
>> accidental matches with arm* in various bits of configery so leaving
>> that alone probably makes sense despite the silly name. 
>
>How much of the arm* silliness is there actually? There's already quite
>significant changes between various arm sub-architectures, so matching
>on arm* can already be considered a bad idea.

It's not clear how much out there *is* actually broken like this, to
be honest. But it was one of the concerns raised about the new triplet
for armhf, and for a totally new architecture people are/were very
worried about the possibility of breakage. There is already historical
precedent for breakage in triplet naming...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer


-- 
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/20120723144742.gc27...@einval.com

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

[Roger Leigh]

On Mon, Jul 23, 2012 at 03:26:29PM +0200, Vincent Lefevre wrote:
> On 2012-07-23 07:23:40 -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 23 Jul 2012, Vincent Lefevre wrote:
> > > so that if you want to make things more consistent, you should
> > > get rid of /etc/default entirely.
> > 
> > /etc/default is used for a lot more than just enabling/disabling services,
> > and it will not go away.
> 
> But with /etc/default, you can override options. For instance,
> for sshd, the port can be provided either in /etc/ssh/sshd_config
> or in /etc/default/ssh.

One one and only purpose of a file in /etc/default is to modify
the behaviour of the init script, as an alternative to editing
the script directly (since this causes dpkg conffile prompts and
is quite annoying).

The fact that sshd lets you add additional arbitrary options there
does not make that the intended use or good practice.  It is
neither.

> > Now, if you just mean removing enable/disable switches for initscripts from
> > /etc/default/*, that should be doable with some effort.  And that's what
> > this subthread is about.
> 
> No, I just mean that configuration of some service should be
> in a limited number of places. But if you agree that it's fine
> for /etc/default to override config setup somewhere else, then
> there should not be any problem with ENABLE/DISABLE.

It's not compatible with init systems which do not use the init
scripts directly, e.g. systemd.  A common interface for enabling/
disabling is required, which can then do the system-specific
thing for enabling/disabling.  That should probably be
update-rc.d (though the name is sysvinit-specific).  Since we're
going to be changing the update-rc.d interface in wheezy+1,
maybe we could simply replace it with e.g. update-service and
provide a compatibility wrapper.  And we should ensure that all
init systems provide add/remove/enable/disable actions.  The
stop|start actions are going to simply defer to the "defaults"
action, and will ultimately go.


Regards,
Roger

-- 
  .''`.  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/20120723165920.gm25...@codelibre.net

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

[Thomas Goirand]

On 07/23/2012 07:31 PM, Mike Gabriel wrote:
> * Package name: melange
This name clashes with Openstack Melange.

https://github.com/openstack/melange
http://wiki.openstack.org/Melange
https://launchpad.net/melange/

Please don't use it. This name is *already taken* and used in Ubuntu
(though I don't think this is packaged in Debian ... yet).

It would be really unfortunate that Debian can't use the same package
name as Ubuntu, let's avoid it!

Cheers,

Thomas Goirand (zigo)


-- 
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/500d8df0.50...@debian.org

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

[Paul Tagliamonte]

On Tue, Jul 24, 2012 at 01:46:24AM +0800, Thomas Goirand wrote:
> On 07/23/2012 07:31 PM, Mike Gabriel wrote:
> > * Package name: melange
> This name clashes with Openstack Melange.
> 
> https://github.com/openstack/melange
> http://wiki.openstack.org/Melange
> https://launchpad.net/melange/
> 
> Please don't use it. This name is *already taken* and used in Ubuntu
> (though I don't think this is packaged in Debian ... yet).
> 
> It would be really unfortunate that Debian can't use the same package
> name as Ubuntu, let's avoid it!

This seems an aweful lot like the nodejs / node situation. Let's not let
anyone take "melange" and use cream-melange and openstack-melange :)

No one has any more "right" to the name :)

Ubuntu has gdm3 --> gdm, I mean, it's not unheard of. Although, after
it's upstream, I'm guessing it'll get removed and sunk.

Let's kill off a namespace thing before we get there.

> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> 
> -- 
> 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/500d8df0.50...@debian.org
> 

-- 
 .''`.  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

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

[Russ Allbery]

Antti-Juhani Kaijanaho  writes:
> On Mon, Jul 23, 2012 at 09:08:25AM +0100, Lars Wirzenius wrote:

>> an analogy with the legal system may make things clearer: the press
>> does not announce every decision made by every judge in a court of law,
>> but it does do so for every decision made by the supreme court, whether
>> the case as such is of general interest or not.

> I doubt that's true, though (unless one includes specialized press such
> as SCOTUSblog in the US).

[...]

> Not quite.  Although the US Supreme Court issues less than a hundred
> merits decisions a year, they make a lot more summary decisions (mainly
> denial of certiorari - they exercise their discretion not to hear a
> case) each year, most of which even the courtwatcher press does not
> note.  The numbers are similar, I believe, for the Finnish Supreme
> Court.

Somewhat off-topic, but you're both correct in your own way.  :)  PBS
NewsHour, which is a standard one-hour nightly news program, does indeed
announce every substantive decision of the US Supreme Court, but refusal
to grant cartiorari isn't considered a substantive decision unless there
was some widespread belief that the court would hear the case.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87fw8iz76z@windlord.stanford.edu

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

[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...

# apt-get install -s upstart
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following extra packages will be installed:
  libnih-dbus1 libnih1
The following packages will be REMOVED:
  sysvinit
The following NEW packages will be installed:
  libnih-dbus1 libnih1 upstart
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  sysvinit
0 upgraded, 3 newly installed, 1 to remove and 17 not upgraded.
Remv sysvinit [2.88dsf-28]
[...]

> > Also, 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 might want to look again, then, there are multiple ways to disable a
> daemon using systemd units.

OK, the package description of systemd by mentioning the rcN.d links.
I had the impression they were still used.

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.

-- 
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/20120723222818.ga8...@ypig.lip.ens-lyon.fr

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

[Vincent Lefevre]

On 2012-07-23 17:59:21 +0100, Roger Leigh wrote:
> On Mon, Jul 23, 2012 at 03:26:29PM +0200, Vincent Lefevre wrote:
> > No, I just mean that configuration of some service should be
> > in a limited number of places. But if you agree that it's fine
> > for /etc/default to override config setup somewhere else, then
> > there should not be any problem with ENABLE/DISABLE.
> 
> It's not compatible with init systems which do not use the init
> scripts directly, e.g. systemd.

I don't understand. If systemd does not use the init scripts directly,
how can it be aware of the way to start the daemon?

If you want an example, there's wicd-daemon, which just provides an
init script and has an ENABLE/DISABLE switch in /etc/default/wicd.

> A common interface for enabling/disabling is required, which can
> then do the system-specific thing for enabling/disabling. That
> should probably be update-rc.d (though the name is
> sysvinit-specific). Since we're going to be changing the update-rc.d
> interface in wheezy+1, maybe we could simply replace it with e.g.
> update-service and provide a compatibility wrapper. And we should
> ensure that all init systems provide add/remove/enable/disable
> actions. The stop|start actions are going to simply defer to the
> "defaults" action, and will ultimately go.

A common interface would be nice. But what if there are multiple
ways to disable a daemon (as mentioned by Tollef Fog Heen)? I think
that it should be flexible enough so that the user can choose.

IMHO it should also provide some logging mechanism for
add/remove/enable/disable actions.

-- 
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/20120723225345.gb8...@ypig.lip.ens-lyon.fr

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

[Russ Allbery]

Vincent Lefevre  writes:

> A common interface would be nice. But what if there are multiple ways to
> disable a daemon (as mentioned by Tollef Fog Heen)? I think that it
> should be flexible enough so that the user can choose.

> IMHO it should also provide some logging mechanism for
> add/remove/enable/disable actions.

Personally, I would love to see us create a common tool that would perform
these sorts of actions for whatever init system one is using, whatever
that may be.  Maybe we can keep update-rc.d as that tool and teach it to
take appropriate action for systemd, upstart, etc., when run with disable
or enable arguments.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87394iuhxo@windlord.stanford.edu

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

[Thomas Goirand]

On Tue Jul 24 2012 02:02:50 AM CST, Paul Tagliamonte  wrote:

> This seems an aweful lot like the nodejs / node situation.

It's very different. Here the clash is at the
package name level, not binaries in /usr/bin.

> Let's not let
> anyone take "melange" and use cream-melange and openstack-melange :)

NO!!! Let's have the same names as in Ubuntu. Or
maybe you want to do the work of convincing them
to change the name? If so, please go ahead, and
come back here when done. Until then, please refrain
from making funny suggestions.

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/1343094621.1948.9.camel@Nokia-N900-42-11

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

[Paul Tagliamonte]

On Tue, Jul 24, 2012 at 09:50:21AM +0800, Thomas Goirand wrote:
> On Tue Jul 24 2012 02:02:50 AM CST, Paul Tagliamonte  
> wrote:
> 
> > This seems an aweful lot like the nodejs / node situation.
> 
> It's very different. Here the clash is at the
> package name level, not binaries in /usr/bin.

node was in /sbin, nodejs is in /usr/bin.

> 
> > Let's not let
> > anyone take "melange" and use cream-melange and openstack-melange :)
> 
> NO!!! Let's have the same names as in Ubuntu. Or
> maybe you want to do the work of convincing them
> to change the name? If so, please go ahead, and
> come back here when done. Until then, please refrain

I'll reply with my Ubuntu email now.

I don't think causing a bigger delta is good for either Debian or
Ubuntu.

Let's please keep the namespace clean. I'll talk with whoever introduced
it, but we can upload a temp metapackage and upload it with time for a
beer after.

> from making funny suggestions.

I assure you I'm not laughing :)

> 
> Thomas
> 

Paul

-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq


signature.asc
Description: Digital signature

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

[Filipus Klutiero]

Steve McIntyre wrote:

Filipus Klutiero whined:
>Steve Langasek wrote:
>>  On Sat, Jul 21, 2012 at 04:38:21PM -0400, Filipus Klutiero wrote:
>>  >
>>  >   although publicity of some resolutions may indeed be useful for a
>>  >   wide range of developers, I fail to see many who would be interested
>>  >   in the resolution on node.
>>
>>  Feel free to filter out mails sent by members of the technical committee to
>>  debian-devel-announce; I will be happy to reciprocate.
>Thank you; also feel free to offer solutions which would be half
>accurate, and consider that there are over 5000 subscribers to
>debian-devel-announce.

Bored now. -1, Troll.


Please try using complete sentences. While you're at it, constructive 
messages would be more productive than name-calling.




[...]



--
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/500e090f.7080...@gmail.com

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

[Filipus Klutiero]

Steve Langasek wrote:


On Sun, Jul 22, 2012 at 07:33:37PM -0400, Filipus Klutiero wrote:
>  Steve Langasek wrote:
>  >On Sat, Jul 21, 2012 at 04:38:21PM -0400, Filipus Klutiero wrote:
>  >>   Stefano Zacchiroli wrote:
>  >>   >On Tue, Jul 17, 2012 at 08:07:15PM -0400, Filipus Klutiero wrote:
>  >>   >>Thank you, but I would appreciate if debian-devel-announce would
>  >>   >>stay dedicated to important announcements which may be useful for 
a
>  >>   >>wide range of developers.

>  >>   >tech-ctte resolutions do fit that bill. The tech-ctte is the highest
>  >>   >dispute resolution body we have in Debian, and I think their doings
>  >>   >deserve this level of awareness in the project.

>  >>   although publicity of some resolutions may indeed be useful for a
>  >>   wide range of developers, I fail to see many who would be interested
>  >>   in the resolution on node.

>  >Feel free to filter out mails sent by members of the technical committee to
>  >debian-devel-announce; I will be happy to reciprocate.
>  Thank you; also feel free to offer solutions which would be half
>  accurate, and consider that there are over 5000 subscribers to
>  debian-devel-announce.

Ok, let me be a little clearer.

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.


  [...]

Your lone opinion is therefore *entirely* irrelevant to the question of how
the debian-devel-announce mailing list is used.  If there were support for
your position from other DDs, it would be worth discussing.  There hasn't
been any such support, yet you've persisted in asserting the mailing list
content should be adapted to your personal preferences.

You would have done well to recognize that yours was a lone opinion and find
a way to adapt your habits to the majority view instead of demanding the
converse.  You have failed to do so, and in the process have made yourself a
nuisance.  You have now wasted far more of Debian's time with this little
d-d-a jihad than could possibly have been wasted by the original
announcement.


Lone opinion? d-d-a jihad?


Welcome to my kill file.


You would have done well to see the code of conduct and find a way to 
adapt your communication style to the majority view.



--
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/500e0a7c.9050...@gmail.com

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

[Filipus Klutiero]

Lars Wirzenius wrote:

On Sun, Jul 22, 2012 at 07:49:50PM -0400, Filipus Klutiero wrote:
>  Hi Lars,
>
>  Lars Wirzenius wrote:
>
>  >On Sat, Jul 21, 2012 at 04:38:21PM -0400, Filipus Klutiero wrote:
>  >>   Hi Stefano,
>  >>
>  >>   Stefano Zacchiroli wrote:
>  >>   >On Tue, Jul 17, 2012 at 08:07:15PM -0400, Filipus Klutiero wrote:
>  >>   >>Thank you, but I would appreciate if debian-devel-announce would
>  >>   >>stay dedicated to important announcements which may be useful for 
a
>  >>   >>wide range of developers.
>  >>   >
>  >>   >tech-ctte resolutions do fit that bill. The tech-ctte is the highest
>  >>   >dispute resolution body we have in Debian, and I think their doings
>  >>   >deserve this level of awareness in the project.
>  >>
>  >>   although publicity of some resolutions may indeed be useful for a
>  >>   wide range of developers, I fail to see many who would be interested
>  >>   in the resolution on node.
>  >
>  >You're complaining about the posting volume of a list that has 13 +
>  >17 + 16 + 7 + 8 + 10 + 4 = 75 messages this year, or about 2.6 days
>  >between posts.
>
>  No, I simply explained it would have been better to send the message
>  in question elsewhere, avoiding debian-devel-announce.

I stand by my claim.


Then quote where you think I did such a thing,


  It may be
>  that there are few messages in this situation, and that more
>  messages were in the opposite situation and should have been sent to
>  debian-devel-announce.
>  >[...]
>  >
>  >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.
>
>  Conflicts are intrinsic in projects divided into thousands of
>  inter-dependent sub-projects with private decision-making
>  processes... I would be more worried to see no conflicts in our
>  system.

Yes, conflicts certainly are inevitable. When they escalate to the second
highest decision-making body in the project, which makes a decision,
that is clearly important enough that it warrants an announcement to
the entire membership of the Debian project.


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.




Although the Technical Committee is not a judge, an analogy with the
legal system may make things clearer: the press does not announce every
decision made by every judge in a court of law, but it does do so for
every decision made by the supreme court, whether the case as such is of
general interest or not. This is important so that the general population
can keep an eye on those in power. It's also important so we know what's
going on and can learn. It does not matter if it generates a small amount
of extra items in the newspaper, since the total volume of supreme court
decisions is quite low.

Like Steve and Steve, I'm not going to debate this further with you.
I'm not going to killfile you, but I suggest you find ways in which you
can help Debian development in constructive ways, rather than this kind
of idiotic distraction.


Which kind of idiotic distraction?


So far, I admit I don't see you as a helpful
part of the Debian development community, and I wish you would rectify
the situation: preferably by starting to do things, but otherwise by
leaving.


For my part, I think you generally help Debian, and hope you don't start 
spreading misinformation, but rather keep doing constructive work.



--
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/500e0fd5.90...@gmail.com

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

[Scott Kitterman]

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.  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.  Whatever 
the merits of you position, there's no point in continuing.

When I was growing up, I recall a common saying was "Once you realize you're 
in a hole, stop digging."  You are in a hole.  Please stop diggin.

Scott K


-- 
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/1880818.jnTd0noSDr@scott-latitude-e6320

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

[Russ Allbery]

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 don't think any purpose is served by continuing to discuss it right now.
It doesn't seem likely that any new arguments will be presented or that
any older arguments will suddenly become more persuasive (to either you or
to anyone else), so for the time being we're not going to reach unanimous
agreement on a course of action.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87y5m9u9cj@windlord.stanford.edu

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

[Charles Plessy]

Le Mon, Jul 23, 2012 at 10:22:06PM -0400, Paul Tagliamonte a écrit :
> 
> Let's please keep the namespace clean. I'll talk with whoever introduced
> it, but we can upload a temp metapackage and upload it with time for a
> beer after.

Hi all,

I agree with Paul.  Our downstream distributions do not have the same
constraints as us.  If we want to to stay "universal", we need to send a strong
message that short, common dictionary words are better be avoided in the
interest of all.

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.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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/20120724040014.ga7...@falafel.plessy.net

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

[The Fungi]

On 2012-07-24 13:00:14 +0900 (+0900), Charles Plessy wrote:
[...]
> short, common dictionary words are better be avoided in the
> interest of all.
[...]

For executables launched through automated processes or some GUI, I
can more or less agree. However, for tools invoked regularly from a
shell prompt this does not hold. I'm grateful tools like calc,
calendar, dict and so on do not have me constantly invoking them as
crazy-long-hypen-words at the command line, but instead consist of
short and descriptive terms within my execution path. I'd even go so
far as to suggest that short, common dictionary words should be
reserved in the executable namespace for precisely these CLI sorts
of uses.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }


-- 
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/20120724041815.gj3...@yuggoth.org

Re: glibc very old

[Miles Bader]

Vincent Lefevre  writes:
>> Based on a glance at the source, it seems like the math libraries
>> were changed in lots of little ways between 2.13 and 2.16 [and it
>> looks like the FPU-twiddling that made expf slow in 2.13 has been
>> _added_ to the generic version of the "exp" (double-precision)
>> function, meaning it might actually be (much) _slower_ in 2.16 on
>> ports without optimized implementations... :( ]
>
> However (if this is the change I'm thinking of) this makes math
> functions "correct" in directed rounding modes and potentially more
> secure.
>
> 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?

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

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 ... */

thanks,

-miles

-- 
Alone, adj. In bad company.


-- 
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/87d33lhinf@catnip.gol.com

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

[Guillem Jover]

Hi!

On Tue, 2012-07-24 at 13:00:14 +0900, Charles Plessy wrote:
> Le Mon, Jul 23, 2012 at 10:22:06PM -0400, Paul Tagliamonte a écrit :
> > Let's please keep the namespace clean. I'll talk with whoever introduced
> > it, but we can upload a temp metapackage and upload it with time for a
> > beer after.

> I agree with Paul.  Our downstream distributions do not have the same
> constraints as us.  If we want to to stay "universal", we need to send
> a strong message that short, common dictionary words are better be
> avoided in the interest of all.

While I agree that when it comes to a distribution it's really very
important that we take care of the namespace_s_, which are not only
package names, but command names, shared library names, C header file
names, etc, I strongly disagree a simple rule as “do not use common
dictionary words” would be good or appropriate at all. Namespaces are
all about context.

One thing is to name your text editor just “editor” or your browser
“browser”, the other is naming it dolphin, which is also a common
dictionary word.

Another difference would be if your implementation is either generic
or field specific, an example could be libmaildir4 which used to be a
KDE specific library to handle Maildir mail boxes, if that would have
been a generic low-level toolkit-neutral implementation, I think it
would have been ok-ish, but not as it was (which ideally should have
been named libkmaildir4). The same applies to command-line tools, if
your tool is called «add» but is used for stuff related to chromosome
additions then I'd say that's really not appropriate, but if it's used
to compute the addition of two files filled with numbers then that'd
seem better (preferibly if it comes from an existing base package).

Or if someone devises a new tool named “feather” and suddenly it
proves to be very useful, and lots of clones appear, then those would
be feather-clones, and it would not be appropriate to make the
original change its name, in the same way the original vi was just
vi, and the subsequent clones got their variant names (nvi, vim, etc).

And we have to take into account that a huge amount of computing terms
come from metaphors from real life or other fields or simple reuse of
generic words, so outright banning common dictionary words would mean
we cannnot name new things to come.

regards,
guillem


-- 
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/20120724061134.ga5...@gaara.hadrons.org

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

[Tollef Fog Heen]

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

[...]

> > > Also, 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 might want to look again, then, there are multiple ways to disable a
> > daemon using systemd units.
> 
> 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.

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

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)

-- 
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/87ipddel9w@xoog.err.no

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

[Tollef Fog Heen]

]] Russ Allbery 

> Personally, I would love to see us create a common tool that would perform
> these sorts of actions for whatever init system one is using, whatever
> that may be.  Maybe we can keep update-rc.d as that tool and teach it to
> take appropriate action for systemd, upstart, etc., when run with disable
> or enable arguments.

A patch to do this in update-rc.d for .service files was recently sent
to pkg-sysvinit-devel, so while it won't be in wheezy (I assume), it'll
be there quickly afterwards.

-- 
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/87eho1el7z@xoog.err.no

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

[Tollef Fog Heen]

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

-- 
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/87a9ypekyw@xoog.err.no

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

[Thomas Goirand]

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
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
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).

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