Re: switching from exim to postfix

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:

> Is this the right time to do it?

I'm not sure that I see the point, and I say that as someone who replaces
Exim with Postfix on all of my boxes.

There's nothing particularly wrong with Exim; it works just fine.  It's
been the default in Debian for years, and it's actively maintained
upstream.  And it's completely trivial to replace it with Postfix if one
desires.  The disruption doesn't seem worth it even if we had consensus
that Postfix was marginally better in some way.

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

switching from exim to postfix

[Marco d'Itri]

Is this the right time to do it?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#670786: ITP: despotify -- Open source client for Spotify

[Toby Smithe]

Package: wnpp
Severity: wishlist
Owner: Toby Smithe 

* Package name: despotify
  Version : 1.0r520
  Upstream Author : #HACK.SE 
* URL : http://despotify.se/
* License : 2-clause BSD
  Programming Lang: C
  Description : Open source client for Spotify

Despotify is an independent open source client for the Spotify streaming music
platform, which provides on-demand access to music from a number of major and
independent record labels. To use despotify, a Spotify Premium account is
required.

The source package builds three binaries:
 libdespotify0, libdespotify0-dev, and despotify.

The binary package "despotify" provides two console front-ends, and one HTTP
REST front-end. The two library packages are self-explanatory. I intend to
investigate also building the python and ruby bindings, but I have not yet
looked into that.

For answers about the legal situation and the relationship of despotify with
the official proprietary distribution, please see .



-- 
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/20120428235733.8689.85900.reportbug@leopard

Bug#670785: ITP: libxml-writer-string-perl -- Capture output from XML::Writer

[韓達耐]

Package: wnpp
Owner: Danai SAE-HAN (韓達耐) 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libxml-writer-string-perl
  Version : 0.1
  Upstream Author : Simon Oliver 
* URL : http://search.cpan.org/dist/XML-Writer-String/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Capture output from XML::Writer.

XML::Writer::String implements a bare-bones class specifically for the
purpose of capturing data from the XML::Writer module. XML::Writer expects an
IO::Handle object and writes XML data to the specified object (or STDOUT) via
it's print() method. This module simulates such an object for the specific
purpose of providing the required print() method.

It is recommended that $writer->end() is called prior to calling $s->value()
to check for well-formedness.



--
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/calr4ymfk8qlcndbttm6ue67ynq9n-uskqqtnrotq65wid+r...@mail.gmail.com

Re: MIA check: Jan Christoph Nordholz

[Sune Vuorela]

On 2012-04-28, Dmitry Smirnov  wrote:
> I'm looking for information regarding last known activity of=20
>
>Jan Christoph Nordholz 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641867#20 is what he
wrote on another package some months ago.

/Sune


-- 
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/slrnjporoi.p7v.nos...@sshway.ssh.pusling.com

Re: MIA check: Jan Christoph Nordholz

[Petter Reinholdtsen]

[Dmitry Smirnov]
> Petter, you sponsored last maintainer's upload back in 2009 - do you
> happen to hear from Jan lately?

Nope.  Been busy elsewhere. :)
-- 
Happy hacking
Petter Reinholdtsen


-- 
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/2flmx5v4mk4@diskless.uio.no

Re: Node.js and it's future in debian

[Chris Knadle]

On Saturday, April 28, 2012 13:23:21, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> > I also am biased in one direction but shall not say which as I see no
> > benefit at this point in rehashing the discussion: Both packaging
> > "camps" have clearly demonstrated a lack of interest in letting the
> > other use the name "node", which means we must both step off of it.
> > 
> > Just today there was progress on the side of Node.js - see bug#650343.
> 
> I think that having Node.js not provide the command node would be a real
> disservice to our users (and I say this as someone in neither camp; I've
> never used either program).

In terms of Debian dependencies, there don't seem to be any packages that 
depend on the 'node' package from the hamradio section.  This makes it tougher 
to know what depends on the binary being named 'node'.

A problem with the name 'node' is that it's painful to web search that name to 
try to find out what the project is for.  :-/  This is another reason not to 
like the use of such a generic name.



The hamradio 'node' program looks like it is meant to support several packet 
radio protocols, either for a computer acting as a "packet radio router", 
"packet radio BBS" (bulletin-board system) or possibly for a "user end-node".  
I believe all of these invovle a computer being hooked up to a TNC [Terminal 
Node Controller] which is then hooked up to a radio.

For an example of what a TNC looks like, see [1].

Generally packet radio involves low data rate communication.  At VHF 
frequencies this is generally limited to 1200 baud simplex ("simplex" means 
not being able to receive during transmission, whereas "duplex" means being 
able to do both simultaneously) -- so the actual throughput is always quite a 
bit less than the transmission baud rate.  At UHF frequencies due to wider 
channels the packet can be a bit faster -- up to 9600 baud.  [At SHF and 
higher frequencies data rates can be faster

Some TNCs also support other things such as slow scan TV reception, Morse 
Code, RTTY, "packet email" (stored in the TNC momory, blinking light to 
indicate a message is waiting), packet message forwarding (so that a message 
from New York eventually is received in some other part of the country, all 
over radio), etc.

Due to low data rates, packet radio isn't as popular today as it was in the 
1990's, when telephone modems that were typically in use were also slow.  [The 
early 90's is when I was doing packet radio.]


[1] http://www.timewave.com/support/PK-232/PK232DSP.html

  -- Chris

--
Chris Knadle, KB2IQN
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


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

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Jonas Smedegaard]

On 12-04-28 at 01:50pm, Joey Hess wrote:
> Jonas Smedegaard wrote:
> > As I understand the current status, it has already on this list been 
> > resolved that *both* packages should back off from using the 
> > clashing name "node".
> > 
> > I also am biased in one direction but shall not say which as I see 
> > no benefit at this point in rehashing the discussion: Both packaging 
> > "camps" have clearly demonstrated a lack of interest in letting the 
> > other use the name "node", which means we must both step off of it.
> 
> Just because someone read policy or whatever it was in a way that 
> requires this King Solomonesque approach to this sort of conflict, 
> does not actually mean that it makes sense to me, or I hope, to most 
> of us. It's certianly not the fait accompli you make it out to be.
> 
> There is a transition plan and patch for the (ham radio) node in
> #614907. Nobody has been able to demonstate any appreciable problems
> with renaming it. Indeed, noone has demonstrated any likely reason for 
> its "node" command to be run directly.

Seems the issue is getting rehashing anyway, so let me "reveal" that my 
bias is on the side of renaming the ham radio daemon and allow Node.js 
to use "node", because a) I have so far failed to locate any sensible 
explanation from the ham radio camp why they must keep the name, and b) 
Node.js is becoming quite popular and is known generally to use "node" 
in its hash-bang.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Joey Hess]

Jonas Smedegaard wrote:
> As I understand the current status, it has already on this list been 
> resolved that *both* packages should back off from using the clashing 
> name "node".
> 
> I also am biased in one direction but shall not say which as I see no 
> benefit at this point in rehashing the discussion: Both packaging 
> "camps" have clearly demonstrated a lack of interest in letting the 
> other use the name "node", which means we must both step off of it.

Just because someone read policy or whatever it was in a way that
requires this King Solomonesque approach to this sort of conflict, does
not actually mean that it makes sense to me, or I hope, to most of us.
It's certianly not the fait accompli you make it out to be.

There is a transition plan and patch for the (ham radio) node in
#614907. Nobody has been able to demonstate any appreciable problems
with renaming it. Indeed, noone has demonstrated any likely reason
for its "node" command to be run directly.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 04/28/2012 08:29 AM, Vincent Bernat wrote:
> We are in 2012 and if a non-essential daemon blocks the boot (no working
> network), we have no way to get a getty to be run.
>   
I agree with the rest of your post, but here, you are are
picturing a very badly written init script that doesn't have
a working failure mode! No daemon should block the boot,
even with our current system. If it does, please feel free to
file a bug.

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/4f9c2ed9.3040...@debian.org

Re: Node.js and it's future in debian

[Carsten Hey]

* Carl Fürstenberg [2012-04-28 03:31 +0200]
> The the hamradio package "node" shipping a binary called "node", and
> as it's so old, the developers argue that the package must ship
> a binary called "node" or breakage will occur.

Upstream's INSTALL file contains:
| Node is intended to be called from ax25d or inetd. It doesn't need
| any command line arguments but there is one to support incoming
| compressed connects. See the node(8) manual page.

So the breakage is that people would need to update their config files?


* Roger Leigh [2012-04-28 10:41 +0100]:
> From a purely pragmatic POV, how many people are using both packages?

I don't think that the answer is zero, but I also don't think that the
answer is that far away from zero.

node ships /usr/sbin/node and nodejs ships /usr/bin/node, so there is no
file conflict from dpkg's point of view and if only one of both packages
is installed, then things just work.

Only for those cases where users install both packages, a special
solution needs to be found.

hamradio's node only accepts one option, -c, no other arguments.  If
nodejs is invoked with this option it responds with "Error: unrecognized
flag -c" (but still enters its interactive mode).  If nodejs' upstream
agrees to never add this option, it is easy to detect which node is
intended to be run unless node is invoked without any arguments.  If
used in a shebang line, there is always an argument that is not '-c'.

nodesjs evaluates what it reads from stdin; if hamradio's node does not
do anything with stdin (I'm not sure about this), the remaining cases
where it is not clear which node should be run would be when it is
invoked without any arguments and if test -p /dev/stdin is false.

If the few users that install node and nodejs would be asked which one
should be invoked if run without any arguments, both node binaries in
their path could be diverted away and replaced with something similar to
the shell snippet below (yes, I know that alternatives does not really
fit here, that "[ -p /dev/stdin ]" might need to be removed and that
a wrapper written in C might be more robust).

  #!/bin/sh
  if [ $# -eq 1 ] && [ "$1" = "-c" ]; then
  exec /usr/sbin/hamnode -c
  elif [ $# -ge 1 ] || [ -p /dev/stdin ]; then
  exec /usr/bin/jsnode "$@"
  else
  exec /etc/alternatives/node
  fi

Since nodejs will be installed by way more people and the amount of
questions should IMHO be kept low, I think that this magic should either
be in the package node; or be in both packages in a way that avoids
questions to be asked if only one package of the two packages is
installed.


Carsten


-- 
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/20120428170919.ga30...@furrball.stateful.de

Re: Node.js and it's future in debian

[Russ Allbery]

Jonas Smedegaard  writes:

> I also am biased in one direction but shall not say which as I see no 
> benefit at this point in rehashing the discussion: Both packaging 
> "camps" have clearly demonstrated a lack of interest in letting the 
> other use the name "node", which means we must both step off of it.

> Just today there was progress on the side of Node.js - see bug#650343.

I think that having Node.js not provide the command node would be a real
disservice to our users (and I say this as someone in neither camp; I've
never used either program).

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

Re: Node.js and it's future in debian

[Russ Allbery]

"brian m. carlson"  writes:
> On Sat, Apr 28, 2012 at 10:41:36AM +0100, Roger Leigh wrote:

>> From a purely pragmatic POV, how many people are using both packages?
>> If the answer is zero, and this seems relatively likely, can't we just
>> add a Conflicts/Breaks and be done with it.  Not a great solution, but
>> it doesn't seem like there's a better one if both camps are unwilling
>> to change.

> Policy specifically forbids this.  If Policy did not specifically forbid
> this, it is my understanding that this would already have been done (and
> was already done, but was forced to be reverted).

Well, Policy can be changed; the reason why Policy says that (I believe)
is because we don't want to artificially limit what packages our users
want to use in conjunction with each other.  It's not necessarily
overriding.  I'd prefer the conflict to the current state, personally,
although it's still not a really good solution.

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

Re: Node.js and it's future in debian

[brian m. carlson]

On Sat, Apr 28, 2012 at 10:41:36AM +0100, Roger Leigh wrote:
> >From a purely pragmatic POV, how many people are using both packages?
> If the answer is zero, and this seems relatively likely, can't we
> just add a Conflicts/Breaks and be done with it.  Not a great solution,
> but it doesn't seem like there's a better one if both camps are
> unwilling to change.

Policy specifically forbids this.  If Policy did not specifically forbid
this, it is my understanding that this would already have been done (and
was already done, but was forced to be reverted).

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: biber (from TeXLive 2011) crashes on Debian testing/unstable

[Marcus Frings]

* Henrique de Moraes Holschuh  wrote:

> NULL pointer derreference.

> Install the -dbg packages for all libraries used by biber, compile biber
> with full debug information, and try running texl (the binary which is
> segfaulting) under gdb (maybe using xgdb or ddd to make it easier).  You
> should be able to pinpoint what function of libc it is calling with a NULL
> pointer.

> Maybe you can even find that out by just using "ltrace" instead of strace
> and gdb on the binary with full debug information...

Thank you very much for your answer, Henrique! I'll forward your answer
to the author of biber and hope that it can be fixed soon.

Best regards,
Marcus
-- 
"As the water flows over the bridge,
As we walk on the floodland,
As we walk on the water, we forget."


-- 
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/vita-brevis-breviter-in-brevi-finietur-mors-venit-velociter-quae-neminem-veretur-87aa1v7u6z@shodan.gothgoose.net

Re: biber (from TeXLive 2011) crashes on Debian testing/unstable

[Marcus Frings]

* Marcus Frings  wrote:

> I'm running Debian unstable (32 bit) on various machines with local
> installations of TeXLive 2011 (both Debian and TeXLive are updated
> daily). Since a few days biber (which is part of TeXLive and replaces
> the old bibtex) crashes on all machines with a segmentation fault:

Just an update. In the meantime, Philip Kime who is the author of biber
also called for help in the newsgroup comp.text.tex:

http://groups.google.com/group/comp.text.tex/browse_thread/thread/dd6ff2735f148afe?hl=de#

Best regards,
Marcus
-- 
Post mortem, stirred tarantulas trill H through lung-books
lined with gauze. Their cerci writhe outside the frame
  and scythes of come
  spell "No One's Home". (Rob Hardin: nerve terminals)


pgpJTTxD9BLrX.pgp
Description: PGP signature

Re: biber (from TeXLive 2011) crashes on Debian testing/unstable

[Henrique de Moraes Holschuh]

On Sat, 28 Apr 2012, Marcus Frings wrote:
> Apr 28 12:25:52 black-ice kernel: [1216918.909369]
> /usr/local/texl[14001]: segfault at 0 ip b7591a11 sp bfd15c8c error 4 in
> libc-2.13.so[b7515000+156000]

NULL pointer derreference.

> I have uploaded the output of "strace biber --version" to
> http://pastebin.com/eeLZVwpz>. Would anyone be willing to help me?

Install the -dbg packages for all libraries used by biber, compile biber
with full debug information, and try running texl (the binary which is
segfaulting) under gdb (maybe using xgdb or ddd to make it easier).  You
should be able to pinpoint what function of libc it is calling with a NULL
pointer.

Maybe you can even find that out by just using "ltrace" instead of strace
and gdb on the binary with full debug information...

-- 
  "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/20120428150733.ga31...@khazad-dum.debian.net

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Jonas Smedegaard]

On 12-04-28 at 03:31am, Carl Fürstenberg wrote:
> There has been an log struggle between the nodejs package and the node 
> package, which is still unresolved (bug #611698 for example) And I 
> wonder now what the future should look like.
> 
> To summarize the problem:
> * the nodejs upstream binary is called "node", and the upstream
> developers have refused to change it's binary name to nodejs for
> debian;
> * The the hamradio package "node" shipping a binary called "node", and
> as it's so old, the developers argue that the package must ship a
> binary called "node" or breakage will occur.
> * The reason the nodejs developers want to ship the binary as "node"
> is because all programs written for nodejs all has /usr/bin/node in
> it's shebang
> * the nodejs package are not allowed to conflict on the node package
> just because the binary name is the same
> 
> As I'm not a hamradio user, I'm off course biased towards letting 
> nodejs having the "node" binary and let it pass to testing. But we 
> must find a solution to this, as nodejs is getting more and more used, 
> and developers are forced to install nodejs from source to be able to 
> use it instead of install it via the package manager.

As I understand the current status, it has already on this list been 
resolved that *both* packages should back off from using the clashing 
name "node".

I also am biased in one direction but shall not say which as I see no 
benefit at this point in rehashing the discussion: Both packaging 
"camps" have clearly demonstrated a lack of interest in letting the 
other use the name "node", which means we must both step off of it.

Just today there was progress on the side of Node.js - see bug#650343.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

biber (from TeXLive 2011) crashes on Debian testing/unstable

[Marcus Frings]

Hello everyone,

before asking here I have tried the German user mailing list of Debian
and comp.text.tex, too, but nobody could help me there, yet. So please
forgive me for sending my concern directly to the DD list.

I'm running Debian unstable (32 bit) on various machines with local
installations of TeXLive 2011 (both Debian and TeXLive are updated
daily). Since a few days biber (which is part of TeXLive and replaces
the old bibtex) crashes on all machines with a segmentation fault:

[12:25][marcus@black-ice:~]$ biber -version
Segmentation fault

Apr 28 12:25:52 black-ice kernel: [1216918.909369]
/usr/local/texl[14001]: segfault at 0 ip b7591a11 sp bfd15c8c error 4 in
libc-2.13.so[b7515000+156000]

This segmentation fault also happens on a fresh install of Debian
testing (I used the Debian netinstall image from April 26).

biber can also be downloaded directly from
http://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/>
and both the official release 0.9.9 and the development version give a
segfault.

I have reported this issue to Philip Kime, the author of biber, and he
confirmed the crash. There was a similar issue on Debian testing 64 bit
but now biber seems to work again on 64 bit:

http://sourceforge.net/tracker/?func=detail&aid=3519958&group_id=228270&atid=1073792

However, biber still fails to run on the 32 bit version of Debian
testing/unstable. I'm still in contact with Philip but he could not find
a solution, yet, and asked me to ask the Debian people for help.
Unfortunately, I wasn't able to figure out myself which recent change in
Debian triggers the crash and makes biber incompatible with current
Debian versions.

I have uploaded the output of "strace biber --version" to
http://pastebin.com/eeLZVwpz>. Would anyone be willing to help me?

Best regards,
Marcus
-- 
Bender: "Ahhh, what an awful dream. Ones and zeroes everywhere... and I thought
 I saw a two."


pgp0f3RZirso4.pgp
Description: PGP signature

Re: libbitcoin

[Amir Taaki]

> We have a process for requesting software to be packaged for Debian

> (RFPs), please read the following:
>
> http://www.debian.org/devel/wnpp/

Thanks. Here it is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670701

-
Submit this report on wnpp (e to edit) [Y|n|a|c|e|i|l|m|p|q|d|t|s|?]? 
Bug report written as /var/tmp/wnpp.bug

If you want to provide additional information, please wait to receive the bug 
tracking number via email; you may then send any extra information to 
n...@bugs.debian.org (e.g. 999...@bugs.debian.org), where n is the
bug number. Normally you will receive an acknowledgement via email including 
the bug report number within an hour; if you haven't received a confirmation, 
then the bug reporting process failed at some point
(reportbug or MTA failure, BTS maintenance, etc.).
-

However when I check the wnpp RFP bug list, my package never arrives: 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp


-- 
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/1335608730.81687.yahoomail...@web121006.mail.ne1.yahoo.com

Re: Node.js and it's future in debian

[Roger Leigh]

On Fri, Apr 27, 2012 at 07:14:04PM -0700, Russ Allbery wrote:
> Carl Fürstenberg  writes:
> 
> > As I'm not a hamradio user, I'm off course biased towards letting nodejs
> > having the "node" binary and let it pass to testing. But we must find a
> > solution to this, as nodejs is getting more and more used, and
> > developers are forced to install nodejs from source to be able to use it
> > instead of install it via the package manager.
> 
> This increasingly feels like the same situation as Git: yes, another
> utility was first, but the usage of one is a tiny fraction of the usage of
> the other, and people expecting to use a common package expect it to be
> available under that name and think poorly of Debian when it doesn't just
> work.

>From a purely pragmatic POV, how many people are using both packages?
If the answer is zero, and this seems relatively likely, can't we
just add a Conflicts/Breaks and be done with it.  Not a great solution,
but it doesn't seem like there's a better one if both camps are
unwilling to change.


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/20120428094136.gh28...@codelibre.net

Re: Node.js and it's future in debian

[Adrian Knoth]

On Fri, Apr 27, 2012 at 07:14:04PM -0700, Russ Allbery wrote:

[nodejs's vs. hamradio's /usr/bin/node]
> In an ideal world, *neither* application would be using "node", since it's
> a very generic name

You could rename the binary in both packages and then ask the user via
debconf and/or alternatives whether to set a symlink to "node" and if
so, to which one (node-js or node-hamradio).

Within Debian, nothing should reference /usr/bin/node, but node-js or
node-hamradio. The symlink is then only required for 3rd party code.

Granted, this can still break for those who have 3rd party hamradio
scripts and 3rd party node-js stuff both referring to "node", but
that's exactly the problem you have right now.


Just my €0.02

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver


-- 
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/20120428092523.gl6...@ltw.loris.tv

Re: RFC: OpenRC as Init System for Debian

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


On Friday 27 April 2012 02:10 AM, Svante Signell wrote:
>> Say you want to mount a network disk during boot.  This depend on
>> the
>>> network being configured.  This in turn might depend on a DHCP
>>> reply from a DHCP server, and to send the DHCP request the
>>> network card need to be detected.  To detect the network card,
>>> the network driver need to be loaded, and the network card need
>>> to be found on the PCI or some other internal bus.  And with
>>> the Linux kernel today, there is no way to know when during
>>> boot the network card will be found on the bus.

> This is the whole cause of the problem: You don't know the names of
> your devices ay longer. Blame Linus! What's the point of changing
> names of peripheral devices "dynamically"? I've been struggling
> with eth0 and eth1 for some rime now, never knowing how it will be
> named for every new kernel :-(
> 

I think he is talking about when the devices get discovered and in
what order. For naming, linux does have ways to guarantee persistent
device names, both for block and network devices.


- -- 
Given the large number of mailing lists I follow, I request you to CC me
in replies for quicker response
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPm6dhAAoJEKY6WKPy4XVpJ4gP/28MSVaq/FcxGzYLZG3U3cog
RvSIv1RcVQfB0N/HuTKSzP19Y0XTPhq7DxJlFwz0c9MgPaUn+W2YngK05XFCGf/S
+zic5zf62pDQymjZ+5M6w+puuzJmbdFYEZdJULBn2e0MzX3b8rZyZulutK5UgMdn
n1W51h2Uq6PpYAE4VQ4WqD/Jo+Bbk3D5f8wy7C38yRPEPSaXNW5seLEU8B2xfQGR
suShUT+06z/BwYLzImKis+vlj8UWYD08h4mLirQt1722w3OU21EMVGDz7+HXIqxe
G4Mggz7wuv7IlxhvxSUitpb3AWHl5Mnnc4vQ+yOKHSHcJsLgOZSfi/ugqHi1YvMm
wTUwqnaEdTPq8cSY78zUJsw+JPmDt7NDmwvL0oWDCvNzwQg5MAxFPFIdLBdznnoT
Wi6Tvse5NheLFgRxUQj+aCtRYAf4FMY6GtVf46IJaeAyrONYPvV7VRA8JOw82wRw
pDirFZjrl/DzXot5LvAbdNpRvOhSFFk6dCoIYVlYvYoBPaNupPC35AvI/waQKseu
eobR/fG7PjwsqQlTr2oiXuh8Oj4ideaNGbdvlVFSh2DBGTEqRZ8EQ0Bkk535d3S2
YkOwHm3lmvAaTD+2SP6A2XHmlvliQC1bDrRvNgFFqRtrVJKk1yQOt3Cu2GZltsOr
dotNNUSr+OST1sBfAZCW
=oGRb
-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/4f9ba762.6040...@researchut.com