trying to overwrite ..., which is also in package ...

[jidanni]

Say, couldn't there be some automatic checks so we users don't encounter
# apt-get dist-upgrade
ERR: trying to overwrite `some file, which is also in package other_package

Happened twice to me today here on sid, #491457, #493711.


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

Re: Not stopping daemons, where are we?

[Steve Langasek]

On Tue, Aug 05, 2008 at 12:44:12PM +0200, Petter Reinholdtsen wrote:

> As far as I am concerned, the boot/shutdown system in Debian do not
> need stop symlinks to kill daemons, as init.d/sendsigs do the same job
> quicker and better, and thus consider all packages doing it to be
> wasting resources.  I would recommend severity normal, as this issue
> is just wasting resources, not breaking functionality.

This is definitely *not* true for a number of services - giving your
database server 5 seconds to flush all its state to disk before it's hard
terminated is not ok.  So I hope you aren't really encouraging people to
file bugs on *all* packages that have [06] shutdown scripts, without
consideration for whether these daemons need to save state...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: Packages getting marked not-for-us

[Michael Casadevall]

Correct me if I'm wrong, but it seems like a pretty bad idea to NFU software
that can be compiled on an architecture even if it doesn't seem that useful.
I have the X11 libraries on my NSLU2, which lacks any graphical output, but
I use it as an X11 server.

That being said, I can see the point from the s390 build admins; as a m68k
porter, I don't think we need to spend the time compiling fight sims and
such for an architecture that has no where close to the processing power to
run it, and thus I can see why NFUing useless packages can help save wear
and tear on the s390 buildds.
Michael
On Tue, Aug 5, 2008 at 4:58 PM, Mark Brown <[EMAIL PROTECTED]> wrote:

> On Tue, Aug 05, 2008 at 12:21:52PM -0500, John Goerzen wrote:
>
> > This seems to happen to me most often on the s390 build daemon, and has
> > happened with at least 3 to 5 different packages now.  (Current example
> > is hpodder).  In fact, I don't think I've ever seen it happen elsewhere.
>
> > It seems to happen when build-deps don't get satisfied, or where there
> > is some problem installing the build-deps.
>
> This is quite common with the s390 buildd - it tends to happen when it
> appears that the package may not be useful on s390 (eg, due to apparing
> to require hardware not available on s390), apparently based on the
> package description.
>
> --
> "You grabbed my hand and we fell into it, like a daydream - or a fever."
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>
>

Re: Packages getting marked not-for-us

[Steve Langasek]

On Wed, Aug 06, 2008 at 12:33:58AM -0400, Michael Casadevall wrote:
> Correct me if I'm wrong, but it seems like a pretty bad idea to NFU software
> that can be compiled on an architecture even if it doesn't seem that useful.
> I have the X11 libraries on my NSLU2, which lacks any graphical output, but
> I use it as an X11 server.

The argument for not building various packages on s390 is that s390 has *no
hardware*, so anything that depends on local hardware to be useful has no
purpose on s390.

That doesn't apply for hpodder, which is not a hardware interface; but
that's a plausible explanation for why the package was put in NFU, if the
buildd maintainer thought it was hardware-dependent.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Scour.com invite from Amit Kumar Sarkar

[Amit Kumar Sarkar]

Hey,

Did you hear about Scour? It is the next gen search engine with
Google/Yahoo/MSN results and user comments all on one page. Best of all we
get paid for using it by earning points with every search, comment and vote.
The points are redeemable for Visa gift cards! It's like earning credit card
or airline points just for searching! Hit the link below to join for free
and we will both get points! 

http://scour.com/invite/amitsarkar/

I know you'll like it!

- Amit Kumar Sarkar


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

Re: Standard way to disable services

[Harald Braumann]

On Thu, 31 Jul 2008 10:56:07 -0400
Guido Günther <[EMAIL PROTECTED]> wrote:

> We might not want to use policy-rc.d as is in sysvinit of filerc
> during startup but we might consider moving these policy decisions
> "no I don't want this daemon at startup, yes I want that daemon
> reloaded after resume" into a policy layer that is independent of the
> underlying init mechanism and which can be queried by the different
> tools be it during system startup/shutdown or after/before suspend
> to/from ram/disk. Cheers,

Is it really necessary? I'm not a big fan of abstraction layers. They
usually complicate things instead of making them easier. So far for me
the sysv init process with its start and kill links is sufficient for
all purposes. It's a simple and stable system. Don't add complicated
cruft on top of it.

I never had the need to restart daemons on suspend/resume. But if this
should be supported, then I'd prefer, if extra runlevels were defined
for going into suspend (similar to rc0.d) and for resuming (similar to
rcS.d)

Cheers,
harry


signature.asc
Description: PGP signature

Re: trying to overwrite ..., which is also in package ...

[Olivier Berger]

Le mercredi 06 août 2008 à 08:14 +0800, [EMAIL PROTECTED] a écrit :
> Say, couldn't there be some automatic checks so we users don't encounter
> # apt-get dist-upgrade
> ERR: trying to overwrite `some file, which is also in package other_package
> 

Did you check :
http://edos.debian.net/missing-conflicts/ ?

It is supposed to do exactly what you're requesting, IMHO.

My 2 cents,

Best regards,
-- 
Olivier BERGER <[EMAIL PROTECTED]>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: trying to overwrite ..., which is also in package ...

[Vincent Danjean]

Olivier Berger wrote:

Le mercredi 06 août 2008 à 08:14 +0800, [EMAIL PROTECTED] a écrit :

Say, couldn't there be some automatic checks so we users don't encounter
# apt-get dist-upgrade
ERR: trying to overwrite `some file, which is also in package other_package



Did you check :
http://edos.debian.net/missing-conflicts/ ?

It is supposed to do exactly what you're requesting, IMHO.


Looking at the description (http://edos.debian.net/missing-conflicts/doc.html)
I'm not sure weather these tests take into account upgrades.
  I mean that, most of the times I see this bug, it comes from a file that
is moved from package oldA to package newB when a new version is published.
Maintainer correctly sets 'Conflicts' (so, for example, oldA cannot be installed
together with newB) but forgot to sets 'Replaces'. So, upgrading from
(oldA, oldB) to (newA, newB) can trigger the bug (depending on the order of
unpacking chosen by apt/dpkg).
  Checking this kind of bugs would need the analyze of two distributions
contents at the same time and upgrade tests.

  So, just for my information, does edos do that ?

  Best regards,
Vincent


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

Re: Packages getting marked not-for-us

[Steve McIntyre]

Steve Langasek wrote:
>On Wed, Aug 06, 2008 at 12:33:58AM -0400, Michael Casadevall wrote:
>> Correct me if I'm wrong, but it seems like a pretty bad idea to NFU software
>> that can be compiled on an architecture even if it doesn't seem that useful.
>> I have the X11 libraries on my NSLU2, which lacks any graphical output, but
>> I use it as an X11 server.
>
>The argument for not building various packages on s390 is that s390 has *no
>hardware*, so anything that depends on local hardware to be useful has no
>purpose on s390.
>
>That doesn't apply for hpodder, which is not a hardware interface; but
>that's a plausible explanation for why the package was put in NFU, if the
>buildd maintainer thought it was hardware-dependent.

It would be nice if buildd admins told people they were doing it, of
course, so that maintainers don't have to guess why their packages
mysteriously aren't being built...

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"You can't barbecue lettuce!" -- Ellie Crane


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

edos, mancoosi - Was: Re: trying to overwrite ..., which is also in package ...

[Olivier Berger]

Le mercredi 06 août 2008 à 11:47 +0200, Vincent Danjean a écrit :
> Olivier Berger wrote:
> > Le mercredi 06 août 2008 à 08:14 +0800, [EMAIL PROTECTED] a écrit :
> >> Say, couldn't there be some automatic checks so we users don't encounter
> >> # apt-get dist-upgrade
> >> ERR: trying to overwrite `some file, which is also in package other_package
> >>
> > 
> > Did you check :
> > http://edos.debian.net/missing-conflicts/ ?
> > 
> > It is supposed to do exactly what you're requesting, IMHO.
> 
> Looking at the description (http://edos.debian.net/missing-conflicts/doc.html)
> I'm not sure weather these tests take into account upgrades.
>I mean that, most of the times I see this bug, it comes from a file that
> is moved from package oldA to package newB when a new version is published.
> Maintainer correctly sets 'Conflicts' (so, for example, oldA cannot be 
> installed
> together with newB) but forgot to sets 'Replaces'. So, upgrading from
> (oldA, oldB) to (newA, newB) can trigger the bug (depending on the order of
> unpacking chosen by apt/dpkg).
>Checking this kind of bugs would need the analyze of two distributions
> contents at the same time and upgrade tests.
> 
>So, just for my information, does edos do that ?
> 

I think it's the purpose of what's coming out of the mancoosi project
(http://www.mancoosi.org/) which follows edos, IIRC.

More details for instance in : http://www.mancoosi.org/deliverables/, or (in 
french) in : 
http://www.systematic-paris-region.org/fr/UserFiles/File/GT%20LL/EdosToMancoosi.pdf

But there are members of EDOS/Mancoosi much more qualified, which read
us, I guess.

Hope this helps,

-- 
Olivier BERGER <[EMAIL PROTECTED]>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Bug#493972: ITP: etherpuppet -- create a virtual interface from a remote Ethernet interface

[Vincent Bernat]

Package: wnpp
Severity: wishlist
Owner: Vincent Bernat <[EMAIL PROTECTED]>

* Package name: etherpuppet
  Version : 0.2
  Upstream Author : Philippe Biondi <[EMAIL PROTECTED]>
* URL : http://www.secdev.org/projects/etherpuppet/
* License : GPL
  Programming Lang: C
  Description : create a virtual interface from a remote Ethernet interface

Etherpuppet is a small program that will create a virtual interface
(TUN/TAP) on one machine from the ethernet interface of another
machine through a TCP connection. Everything seen by the real
interface will be seen by the virtual one. Everything sent to the
virtual interface will be emitted by the real one.

It has been designed because one often has a small machine as his
Internet gateway, and sometimes want to run some big applications that
need raw access to this interface, for sniffing (Ethereal, etc.) or
for crafting packets that do not survive being reassembled, NATed,
etc.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)



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

Bug#493971: ITP: symphonic -- a MP3 file manager for Sony's MP3 players

[Vincent Fourmond]

Package: wnpp
Severity: wishlist
Owner: Vincent Fourmond <[EMAIL PROTECTED]>


* Package name: symphonic
  Version : 0.2.1alpha
  Upstream Author : Patrick Balleux and others
* URL : http://sourceforge.net/projects/symphonic/
* License : GPL
  Programming Lang: Java
  Description : File manager for Sony's MP3 players

 Symphonic is a file manager for Sony's flash players (such as the 
 NW-E00x series), where songs are stored in a proprietary format
 not very Unix-friendly.
 .
 This program provides functionalities similar to the proprietary
 Windows-only SonicStage software given by Sony to interact with
 the players.

The package will be placed under the maintainership of the Debian Java
team.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)



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

Re: Packages getting marked not-for-us

[Matthew Johnson]

On Wed Aug 06 10:42, Steve McIntyre wrote:
> Steve Langasek wrote:
> >On Wed, Aug 06, 2008 at 12:33:58AM -0400, Michael Casadevall wrote:
> >> Correct me if I'm wrong, but it seems like a pretty bad idea to NFU 
> >> software
> >> that can be compiled on an architecture even if it doesn't seem that 
> >> useful.
> >> I have the X11 libraries on my NSLU2, which lacks any graphical output, but
> >> I use it as an X11 server.
> >
> >The argument for not building various packages on s390 is that s390 has *no
> >hardware*, so anything that depends on local hardware to be useful has no
> >purpose on s390.
> >
> >That doesn't apply for hpodder, which is not a hardware interface; but
> >that's a plausible explanation for why the package was put in NFU, if the
> >buildd maintainer thought it was hardware-dependent.
> 
> It would be nice if buildd admins told people they were doing it, of
> course, so that maintainers don't have to guess why their packages
> mysteriously aren't being built...
> 

Or at least didn't block testing migration. I'm happy if porters decide
my package isn't for them, as long as it doesn't stop it being for
anyone else either...

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Bug#493977: ITP: embassy-phylip -- EMBOSS conversions of the programs in the phylip package

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy <[EMAIL PROTECTED]>

  Package name: embassy-phylip
  Version : 3.67
  Upstream Author : The EMBOSS developpers and Joe Felsenstein
  URL : ftp://emboss.open-bio.org/pub/EMBOSS/PHYLIPNEW-3.67.tar.gz
  License : No profit (same as 
http://packages.debian.org/changelogs/pool/non-free/p/phylip/phylip_3.67-3/phylip.copyright)
  Programming Lang: C
  Description : EMBOSS conversions of the programs in the phylip package

 The embassy-phylip programs are EMBOSS conversions of the programs in
 Joe Felsenstein's PHYLIP package, a package of programs for inferring
 phylogenies. These programs all have the prefix "f" to distinguish them
 from the original programs.

A user on the EMBOSS mailing lists expressed his interest for this
package. My approach with non-free works is to only package them on user
request, so I will package embassy-phylip.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team
Tsurumi, Kanagawa, Japan



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

Re: Bug#493972: ITP: etherpuppet -- create a virtual interface from a remote Ethernet interface

[Guus Sliepen]

On Wed, Aug 06, 2008 at 11:44:51AM +0200, Vincent Bernat wrote:

> * Package name: etherpuppet
>   Description : create a virtual interface from a remote Ethernet 
> interface
> 
> Etherpuppet is a small program that will create a virtual interface
> (TUN/TAP) on one machine from the ethernet interface of another
> machine through a TCP connection. Everything seen by the real
> interface will be seen by the virtual one. Everything sent to the
> virtual interface will be emitted by the real one.
> 
> It has been designed because one often has a small machine as his
> Internet gateway, and sometimes want to run some big applications that
> need raw access to this interface, for sniffing (Ethereal, etc.) or
> for crafting packets that do not survive being reassembled, NATed,
> etc.

What is the added value of etherpuppet over existing tools, such as
openvpn, tinc, gvpe, vde2? If there is none, or if the functionality
that is missing from etherpuppet can be easily integrated with one of
the existing tools, then you should tell upstream that it would be
better to invest time and energy in one of the other solutions.

Disclaimer: I'm the upstream and Debian maintainer of tinc.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Bug#493977: ITP: embassy-phylip -- EMBOSS conversions of the programs in the phylip package

[Guus Sliepen]

On Wed, Aug 06, 2008 at 07:31:19PM +0900, Charles Plessy wrote:

>   Package name: embassy-phylip
>   Description : EMBOSS conversions of the programs in the phylip package
> 
>  The embassy-phylip programs are EMBOSS conversions of the programs in
>  Joe Felsenstein's PHYLIP package, a package of programs for inferring
>  phylogenies. These programs all have the prefix "f" to distinguish them
>  from the original programs.

First of all, the description of the package should be self-contained.
If it does the same as the phylip package, then copy the description of
the phylip package, and only add at the end of the description that this
is an "EMBOSS conversion".

Then there is the question what an EMBOSS conversion entails. Why would
one want to use embassy-phylip instead of phylip? The only difference
you describe is that there is an extra "f" in the filename.

If the differences between embassy-phylip and phylip are small, then you
should suggest both upstreams to work together.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Bug#493972: ITP: etherpuppet -- create a virtual interface from a remote Ethernet interface

[Yves-Alexis Perez]

On Wed, Aug 06, 2008 at 01:21:09PM +0200, Guus Sliepen wrote:
> On Wed, Aug 06, 2008 at 11:44:51AM +0200, Vincent Bernat wrote:
> 
> > * Package name: etherpuppet
> >   Description : create a virtual interface from a remote Ethernet 
> > interface
> > 
> > Etherpuppet is a small program that will create a virtual interface
> > (TUN/TAP) on one machine from the ethernet interface of another
> > machine through a TCP connection. Everything seen by the real
> > interface will be seen by the virtual one. Everything sent to the
> > virtual interface will be emitted by the real one.
> > 
> > It has been designed because one often has a small machine as his
> > Internet gateway, and sometimes want to run some big applications that
> > need raw access to this interface, for sniffing (Ethereal, etc.) or
> > for crafting packets that do not survive being reassembled, NATed,
> > etc.
> 
> What is the added value of etherpuppet over existing tools, such as
> openvpn, tinc, gvpe, vde2? If there is none, or if the functionality
> that is missing from etherpuppet can be easily integrated with one of
> the existing tools, then you should tell upstream that it would be
> better to invest time and energy in one of the other solutions.

Well, etherpuppet is not really something to use as a simple vpn. You
use it to really clone (including low level stuff) the interface on the
remote side.

Cheers,
-- 
Yves-Alexis


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

Re: Bug#493972: ITP: etherpuppet -- create a virtual interface from a remote Ethernet interface

[Guus Sliepen]

On Wed, Aug 06, 2008 at 02:10:46PM +0200, Yves-Alexis Perez wrote:

> > What is the added value of etherpuppet over existing tools, such as
> > openvpn, tinc, gvpe, vde2? If there is none, or if the functionality
> > that is missing from etherpuppet can be easily integrated with one of
> > the existing tools, then you should tell upstream that it would be
> > better to invest time and energy in one of the other solutions.
> 
> Well, etherpuppet is not really something to use as a simple vpn. You
> use it to really clone (including low level stuff) the interface on the
> remote side.

Ok, I see now that only one side of the etherpuppet tunnel uses a
tun/tap device, the other side copies everything to/from a real Ethernet
interface.

Still, the other tools I mentioned can all handle Ethernet frames. In
fact, tinc can be compiled to connect to a real Ethernet interface
instead of a tun/tap device, so it might already have the capability to
do what etherpuppet does. The advantage of these tools is that they can
provide encryption, and some of them can connect more than two endpoints
together.

The reason I urge you to consider having upstream merge his
functionality with one of the others is that otherwise there is yet
another tunnel tool out there.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Bug#493977: ITP: embassy-phylip -- EMBOSS conversions of the programs in the phylip package

[Charles Plessy]

Le Wed, Aug 06, 2008 at 01:30:06PM +0200, Guus Sliepen a écrit :
> 
> First of all, the description of the package should be self-contained.
> If it does the same as the phylip package, then copy the description of
> the phylip package, and only add at the end of the description that this
> is an "EMBOSS conversion".
> 
> Then there is the question what an EMBOSS conversion entails. Why would
> one want to use embassy-phylip instead of phylip? The only difference
> you describe is that there is an extra "f" in the filename.
> 
> If the differences between embassy-phylip and phylip are small, then you
> should suggest both upstreams to work together.

Hi Guus,

I hope that the following revised description answers all your questions
at the same time.


 PHYLIP (the PHYLogeny Inference Package) is a package of programs for
 inferring phylogenies (evolutionary trees). Methods that are available
 in the package include parsimony, distance matrix, and likelihood
 methods, including bootstrapping and consensus trees. Data types that
 can be handled include molecular sequences, gene frequencies,
 restriction sites and fragments, distance matrices, and discrete
 characters.
 .
 EMBASSY packages include applications with the same look and feel as
 EMBOSS applications, but which the author wishes to be kept separate
 from EMBOSS. This is usually because the packages are for specialised
 sequence analysis or for non-sequence based anaylsis, or are licensed
 differently to EMBOSS (i.e. non GPL).
 .
 EMBOSS - the European Molecular Biology Open Software Suite - is an
 analysis package specially developed for the needs of the molecular
 biology user community.
 .
 The EMBASSY PHYLIP programs all have the prefix "f" to distinguish them
 from the original programs.

-- 
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan


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

Re: Bug#493972: ITP: etherpuppet -- create a virtual interface from a remote Ethernet interface

[Hamish Moffatt]

On Wed, Aug 06, 2008 at 02:38:36PM +0200, Guus Sliepen wrote:
> On Wed, Aug 06, 2008 at 02:10:46PM +0200, Yves-Alexis Perez wrote:
> 
> > > What is the added value of etherpuppet over existing tools, such as
> > > openvpn, tinc, gvpe, vde2? If there is none, or if the functionality
> > > that is missing from etherpuppet can be easily integrated with one of
> > > the existing tools, then you should tell upstream that it would be
> > > better to invest time and energy in one of the other solutions.
> > 
> > Well, etherpuppet is not really something to use as a simple vpn. You
> > use it to really clone (including low level stuff) the interface on the
> > remote side.
> 
> Ok, I see now that only one side of the etherpuppet tunnel uses a
> tun/tap device, the other side copies everything to/from a real Ethernet
> interface.
> 
> Still, the other tools I mentioned can all handle Ethernet frames. In
> fact, tinc can be compiled to connect to a real Ethernet interface
> instead of a tun/tap device, so it might already have the capability to
> do what etherpuppet does. The advantage of these tools is that they can
> provide encryption, and some of them can connect more than two endpoints
> together.
> 
> The reason I urge you to consider having upstream merge his
> functionality with one of the others is that otherwise there is yet
> another tunnel tool out there.

etherpuppet doesn't sound like a tunnel or VPN tool at all - it seems to
be a mirroring tool for diagnostic purposes.

I'm confused about how TUN/TAP are involved though. If I'm routing
packets between two Ethernet interfaces, can I have them copied to a
third?


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Bug#493977: ITP: embassy-phylip -- EMBOSS conversions of the programs in the phylip package

[Vincent Danjean]

  Hi,

  Here are some comments about the description (done with my wife who
works as biologist with such kind of software).

Charles Plessy wrote:

 PHYLIP (the PHYLogeny Inference Package) is a package of programs for
 inferring phylogenies (evolutionary trees). Methods that are available
 in the package include parsimony, distance matrix, and likelihood
 methods, including bootstrapping and consensus trees. Data types that
 can be handled include molecular sequences, gene frequencies,
 restriction sites and fragments, distance matrices, and discrete
 characters.
 .
 EMBASSY packages include applications with the same look and feel as
 EMBOSS applications, but which the author wishes to be kept separate
 from EMBOSS. This is usually because the packages are for specialised
 sequence analysis or for non-sequence based anaylsis, or are licensed
 differently to EMBOSS (i.e. non GPL).
 .
 EMBOSS - the European Molecular Biology Open Software Suite - is an
 analysis package specially developed for the needs of the molecular
 biology user community.
 .
 The EMBASSY PHYLIP programs all have the prefix "f" to distinguish them
 from the original programs.


EMBOSS should be presented before EMBASSY as EMBASSY use EMBOSS in its
definition.
And we fail to see the relation between EMBOSS and PHYLIP. Does PHYLIP
is a part of EMBOSS ?

Moreover, reading your part on EMBASSY, I understand that EMBOSS is GPL
but not necessarily EMBASSY. Am I right ? (I cannot because PHYLIP is not
free, so either PHYLIP is not a part of EMBOSS or EMBOSS is not all GPL)

Perhaps, you can keep the first paragraph about PHYLIP and then add
something such as:
Original PHYLIP software is not free. EMBASSY PHYLIP is a free rewrite
in the context of the EMBOSS (European Molecular Biology Open Software
Suite) project. The EMBASSY PHYLIP programs all have the prefix "f" to
distinguish them from the original programs.

[of course, I can be totaly wrong if I did not understand the relations
between EMBOSS, EMBASSY and PHYLIP]

  Best regards,
Vincent

--
Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble
Téléphone:  +33 4 76 61 20 11ENSIMAG - antenne de Montbonnot
Fax:+33 4 76 61 20 99ZIRST 51, avenue Jean Kuntzmann
Email: [EMAIL PROTECTED]   38330 Montbonnot Saint Martin


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

Re: Bug#493977: ITP: embassy-phylip -- EMBOSS conversions of the programs in the phylip package

[Charles Plessy]

Hi Vincent,

How about:

 This package is the adaptation of the PHYLIP package in which its
 programs can operate with the biological sequence formats and databases
 of the European Molecular Biology Open Software Suite (EMBOSS). The
 software packages adapted for EMBOSS are called EMBASSY.
 .
 PHYLIP (the PHYLogeny Inference Package) is a package of programs for
 inferring phylogenies (evolutionary trees). Methods that are available
 in the package include parsimony, distance matrix, and likelihood
 methods, including bootstrapping and consensus trees. Data types that
 can be handled include molecular sequences, gene frequencies,
 restriction sites and fragments, distance matrices, and discrete
 characters.
 .
 The EMBASSY PHYLIP programs all have the prefix "f" to distinguish them
 from the original programs and avoid namespace conflict.


> Moreover, reading your part on EMBASSY, I understand that EMBOSS is GPL
> but not necessarily EMBASSY. Am I right ? (I cannot because PHYLIP is not
> free, so either PHYLIP is not a part of EMBOSS or EMBOSS is not all GPL)

Sorry for the confusion. EMBOSS applications are GPL and EMBOSS
libraries are LGPL.


As Andreas pointed out, there is a lot of source duplication between the
PHYLIP and its EMBASSY fork. But building one from the other seems to be
a lot of complication for no benefit, as the EMBASSY PHYLIP programs are
not wrappers.. 


Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan


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

Re: Simplicity Pattern Co. AutoReply

[Ron Wik]

I need help with simplicity pattern #4270 .Jacket G 46&47 . I can"t  
understand your directions. Please call 248-661-8439 Thank-you Mary Wik



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

Re: tagging 231711, tagging 232113, tagging 236498, tagging 241414, tagging 250782, tagging 254248

[Marc Haber]

On Wed, Jan 05, 2005 at 09:16:55PM +0100, Bastian Blank's bts wrote:
> From: Bastian Blank <[EMAIL PROTECTED]>
> Subject: tagging 231711, tagging 232113, tagging 236498, tagging 241414,
>   tagging 250782, tagging 254248
> To: [EMAIL PROTECTED]
> Date: Wed,  5 Jan 2005 21:16:55 +0100
> 
> # Automatically generated email from bts, devscripts version 2.8.6
> tags 231711 wontfix
> tags 232113 wontfix
> tags 236498 wontfix
> tags 241414 wontfix
> tags 250782 wontfix
> tags 254248 wontfix

(all cited bugreports do not contain a single word written by the
package maintainer without using automated tools)

I find it totally unacceptable to tag bugs kommentarlos wontfix
without a single word of explanation why. Five of these bugs are
Debconf translations, the sixth requests more verbose wording of the
single-line _long_ description of cdebootstrap, which is a perfectly
valid request considering that debootstrap and cdebootstrap are both
doing the same job and users should be able to use the long
description to decide which package to use.

Treating bugs like that is impolite, rude, demotivating, and probably
has a bunch of other adjectives apply. Don't treat your users or
translators this way. Please.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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

Re: Bug#493972: ITP: etherpuppet -- create a virtual interface from a remote Ethernet interface

[Vincent Bernat]

OoO  En ce début  d'après-midi nuageux  du mercredi  06 août  2008, vers
14:38, Guus Sliepen <[EMAIL PROTECTED]> disait :

> Ok, I see now that only one side of the etherpuppet tunnel uses a
> tun/tap device, the other side copies everything to/from a real Ethernet
> interface.

> Still, the other tools I mentioned can all handle Ethernet frames. In
> fact, tinc can be compiled to connect to a real Ethernet interface
> instead of a tun/tap device, so it might already have the capability to
> do what etherpuppet does. The advantage of these tools is that they can
> provide encryption, and some of them can connect more than two endpoints
> together.

etherpuppet  is just  a tiny  tool  (one .c)  that does  one thing.  The
documentation of  tinc does not mention that  it is able to  attach to a
real Ethernet  interface. It just  mentions bridges which won't  help in
our case.

> The reason I urge you to consider having upstream merge his
> functionality with one of the others is that otherwise there is yet
> another tunnel tool out there.

As stated by others, etherpuppet is not really a tunnel tool. It is just
a way to make a remote interface a local one. No routing, no switching.
-- 
GOLDFISH DON'T BOUNCE
GOLDFISH DON'T BOUNCE
GOLDFISH DON'T BOUNCE
-+- Bart Simpson on chalkboard in episode 9F14


pgpz3cMu4bRbc.pgp
Description: PGP signature

Re: tagging 231711, tagging 232113, tagging 236498, tagging 241414, tagging 250782, tagging 254248

[Steve Langasek]

On Wed, Aug 06, 2008 at 06:43:00PM +0200, Marc Haber wrote:
> On Wed, Jan 05, 2005 at 09:16:55PM +0100, Bastian Blank's bts wrote:
> > From: Bastian Blank <[EMAIL PROTECTED]>
> > Subject: tagging 231711, tagging 232113, tagging 236498, tagging 241414,
> > tagging 250782, tagging 254248
> > To: [EMAIL PROTECTED]
> > Date: Wed,  5 Jan 2005 21:16:55 +0100
> > 
> > # Automatically generated email from bts, devscripts version 2.8.6
> > tags 231711 wontfix
> > tags 232113 wontfix
> > tags 236498 wontfix
> > tags 241414 wontfix
> > tags 250782 wontfix
> > tags 254248 wontfix

> (all cited bugreports do not contain a single word written by the
> package maintainer without using automated tools)

> I find it totally unacceptable to tag bugs kommentarlos wontfix
> without a single word of explanation why. Five of these bugs are
> Debconf translations, the sixth requests more verbose wording of the
> single-line _long_ description of cdebootstrap, which is a perfectly
> valid request considering that debootstrap and cdebootstrap are both
> doing the same job and users should be able to use the long
> description to decide which package to use.
> 
> Treating bugs like that is impolite, rude, demotivating, and probably
> has a bunch of other adjectives apply. Don't treat your users or
> translators this way. Please.

Not that I think tagging bugs wontfix without explanation is appropriate,
but er, is there no statute of limitations on calling people out on mailing
lists for bad behavior?  The incident you're commenting on is over three
years old!

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Deprecating (and deactivation) of an archive feature?!

[Joerg Jaspert]

Hi

currently our archive has the feature(?) that a source package in component a
(like main) can build a binary package in component b (like contrib).[1]

Now, this feature is blocking (or making it way harder) to do some
database re-designs we want to do for the central archive database, so
we looked if there are real users of it. Well, yes, there are (damnit :) ):


In unstable we have

Christian Holm Christensen <[EMAIL PROTECTED]>
   root-system

Debian ALSA Maintainers <[EMAIL PROTECTED]>
   alsa-tools

Debian GNOME Maintainers <[EMAIL PROTECTED]>
   gnome-speech (U)

Debian Qt/KDE Maintainers <[EMAIL PROTECTED]>
   kdeaccessibility

Bdale Garbee <[EMAIL PROTECTED]>
   gnuradio

Zdenek Kabelac <[EMAIL PROTECTED]>
   avifile

Mario Lang <[EMAIL PROTECTED]>
   gnome-speech

Ana Beatriz Guerrero Lopez <[EMAIL PROTECTED]>
   kdeaccessibility (U)

Mikael Magnusson <[EMAIL PROTECTED]>
   alsa-tools (U)

Jordi Mallach <[EMAIL PROTECTED]>
   alsa-tools (U)

Elimar Riesebieter <[EMAIL PROTECTED]>
   alsa-tools (U)

Kevin M. Rosenberg <[EMAIL PROTECTED]>
   cl-sql

Victor Seva <[EMAIL PROTECTED]>
   linux-wlan-ng

Enrico Tassi <[EMAIL PROTECTED]>
   linux-wlan-ng (U)

Sune Vuorela <[EMAIL PROTECTED]>
   kdeaccessibility (U)

In testing we have avifile gnome-speech alsa-tools linux-wlan-ng cl-sql
kdeaccessibility root-system, in stable avifile linux-uvc alsa-tools
linux-wlan-ng cl-sql kdeaccessibility gnuradio latex-hangul-ucs, and,
just for amusement, oldstable had dvipdfm-cjk bluez-utils
openoffice.org-dictionaries cl-sql synopsis.


Now, the idea would be to deprecate this feature, used by 8 packages in
unstable, dropping complications in the database backend and the pool
layout which we would want to avoid.

Yes, it would require those packages to have a new (additional, maybe
stripped to be smaller) source tarball for the one package in the other
component. Well. 8 of them. A very tiny set compared to the whole
archive, and the question is there if that really means we have to keep
it.


But before we take a final decision I want to hear more input on it. So
here are your 5 seconds, please give input. :)


[1] this would also work with non-free. And by policy the source has to
be in the more-free component.

-- 
bye, Joerg
[...] when an Idea and a developer get laid, code awakes to the world, then
a Debian package is made and pulled in the unstable distribution[...]


pgpM69aSrBmNa.pgp
Description: PGP signature

projectb users - we want you

[Joerg Jaspert]

Hi

as we are currently planning database changes en masse to the projectb,
please, everyone that is using the database (via its copy on merkel
mostly, i think):

Please login to merkel and add yourself to ~joerg/projectb.users (the
file is mode 666, so everyone with login is able to do it).

List a contact name (if you are a team, list that if you want), an email
address where we could reach you, a little description what its for, and
if you can limit it - also the tables/columns you are using from
it. Feel free to do the latter part by just pasting the sql statements
you do.


Reason: As we plan larger database layout changes soon, it would be nice
if we know who to contact right before, so we can coordinate it a
little.


Also, as a user, or potential user, of that database - feel free to let
us know what other data you would like to see in it. We might actually
put it into the database then. (It has to be related to the archive in
some way, so we wont randomly list, eg., bug data or something, but one
example would be adding the descriptions or so).


-- 
bye, Joerg
 eek, 2g is really poo this morning  average of about 2kbps
 I've got faster fax machines
 Gary, I could setup my printer above a fax machine, just faxing IRC to 
you? ;)


pgpertieZc6uP.pgp
Description: PGP signature

Re: Deprecating (and deactivation) of an archive feature?!

[Julien Cristau]

On Wed, Aug  6, 2008 at 20:47:50 +0200, Joerg Jaspert wrote:

> Now, the idea would be to deprecate this feature, used by 8 packages in
> unstable, dropping complications in the database backend and the pool
> layout which we would want to avoid.
> 
Maybe you could tell us what the benefit of dropping this would be (as
in, what are the changes you allude to, and why can't they work with
this feature).

Cheers,
Julien


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

Re: Deprecating (and deactivation) of an archive feature?!

[Russ Allbery]

Joerg Jaspert <[EMAIL PROTECTED]> writes:

> Now, the idea would be to deprecate this feature, used by 8 packages in
> unstable, dropping complications in the database backend and the pool
> layout which we would want to avoid.
>
> Yes, it would require those packages to have a new (additional, maybe
> stripped to be smaller) source tarball for the one package in the other
> component. Well. 8 of them. A very tiny set compared to the whole
> archive, and the question is there if that really means we have to keep
> it.

I have no opinion one way or the other on the change, but wanted to note
that Lintian had previously warned about this and we removed the warning
at the request of one of the maintainers of those packages.  (Bdale, I
think, although I'm not sure.)  So this feature is being intentionally
used at present.

> [1] this would also work with non-free. And by policy the source has to
> be in the more-free component.

Lintian only allows the main to contrib cross; non-free will always get
warnings.  The relevant tag is section-category-mismatch.  (lintian.d.o
doesn't check contrib or non-free, so I don't know if that tag appears
anywhere in the archive.  It doesn't appear for any packages in main,
though.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: tagging 231711, tagging 232113, tagging 236498, tagging 241414, tagging 250782, tagging 254248

[Marc Haber]

On Wed, 6 Aug 2008 11:00:15 -0700, Steve Langasek <[EMAIL PROTECTED]>
wrote:
>Not that I think tagging bugs wontfix without explanation is appropriate,
>but er, is there no statute of limitations on calling people out on mailing
>lists for bad behavior?  The incident you're commenting on is over three
>years old!

Yes, I found my self falling over a three year old bug which has been
(mis)handled in an unacceptable way. The issue still exists, which
makes things even worse.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


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

Re: Packages getting marked not-for-us

[Petter Reinholdtsen]

[Matthew Johnson]
> Or at least didn't block testing migration. I'm happy if porters decide
> my package isn't for them, as long as it doesn't stop it being for
> anyone else either...

I agree.  Perhaps a new rule should be introduced, that when a porter
flag a package as NFU on a given architecture, he should be required
to file a removal request for the binaries on that architecture too,
and CC the package maintainer to let the maintainer know about the
decision.

Silently flagging packages as NFU on a given architecture do not seem
like a good idea, and expecting the maintainer to ask for removal
without letting the maintainer know that the porter refuses to build a
given package can only lead to frustration and friction within the
project.

I assume such removal requests can be scripted, to make it easy for
the porter/buildd maintainer to do.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Not stopping daemons, where are we?

[Petter Reinholdtsen]

[Steve Langasek]
> This is definitely *not* true for a number of services - giving your
> database server 5 seconds to flush all its state to disk before it's
> hard terminated is not ok.  So I hope you aren't really encouraging
> people to file bugs on *all* packages that have [06] shutdown
> scripts, without consideration for whether these daemons need to
> save state...

Nope, I am definitely not doing that. :) Only those that are happy
with a single SIGTERM during shutdown.

Also, note that sendsigs now (since Lenny) will wait for up to 10
seconds for processes to die after the SIGTERM before sending SIGKILL.
The period can be extended if it proves to be too short, but in most
cases I have seen, processes have died within 2-3 seconds.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Deprecating (and deactivation) of an archive feature?!

[Robert Millan]

On Wed, Aug 06, 2008 at 08:47:50PM +0200, Joerg Jaspert wrote:
> 
> But before we take a final decision I want to hear more input on it. So
> here are your 5 seconds, please give input. :)

To me, this sounds like a step in the right direction to unfuzzy the
distinction between Debian itself (main) and the other archives we provide
/support as a supplement to Debian.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Bug#494042: ITP: libhtml-formattext-withlinks-perl -- HTML to text conversion with links as footnotes

[Tim Retout]

Package: wnpp
Severity: wishlist
Owner: Tim Retout <[EMAIL PROTECTED]>

* Package name: libhtml-formattext-withlinks-perl
  Version : 0.11
  Upstream Author : Struan Donald <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/HTML-FormatText-WithLinks/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : HTML to text conversion with links as footnotes

HTML::FormatText::WithLinks takes HTML and turns it into plain text
but prints all the links in the HTML as footnotes. By default, it
attempts to mimic the format of the lynx text based web browser's
--dump option.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)



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

Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools

[Jacob Appelbaum]

Package: wnpp
Severity: wishlist
Owner: Jacob Appelbaum <[EMAIL PROTECTED]>


* Package name: ozymandns
  Version : 0.0.1
  Upstream Author : Dan Kaminsky <[EMAIL PROTECTED]>
* URL : http://www.doxpara.com/ozymandns_src_0.1.tgz
* License : (Currently consulting with upstream for explicit
* license)
  Programming Lang: (C, Perl)
  Description : An experimental DNS server and miscellaneous DNS tools

OzymanDNS is a suite of tools for experimenting with DNS. It includes a
number of tools:

aska.pl - DNS File/Stream Sender
geta.pl - DNS File/Stream Receiver
nomde.pl - Experimental DNS Server
droute.pl - Reliable DNS Transport for standard input/output
glance.c - Represents IP addresses as dates

More information about all of these tools can be found in Dan's Black
Ops DNS 2004 CCC Congress slides:
http://www.ccc.de/congress/2004/fahrplan/files/297-black-ops-of-dns-slides.pdf

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



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

Bug#494048: ITP: libcatalyst-plugin-textile-perl -- Persistent Textile processor for Catalyst

[Tim Retout]

Package: wnpp
Severity: wishlist
Owner: Tim Retout <[EMAIL PROTECTED]>

* Package name: libcatalyst-plugin-textile-perl
  Version : 0.01
  Upstream Author : Sebastian Riedel <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Catalyst-Plugin-Textile/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Persistent Textile processor for Catalyst

Catalyst::Plugin::Textile provides a ready to use Text::Textile object
for convenient Textile formatting in Catalyst applications.

See also the libcatalyst-perl and libtext-textile-perl Debian
packages.



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

Re: Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools

[Steve McIntyre]

Jacob wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Jacob Appelbaum <[EMAIL PROTECTED]>
>
>
>* Package name: ozymandns
>  Version : 0.0.1
>  Upstream Author : Dan Kaminsky <[EMAIL PROTECTED]>
>* URL : http://www.doxpara.com/ozymandns_src_0.1.tgz
>* License : (Currently consulting with upstream for explicit
>* license)
>  Programming Lang: (C, Perl)
>  Description : An experimental DNS server and miscellaneous DNS tools
>
>OzymanDNS is a suite of tools for experimenting with DNS. It includes a
>number of tools:
>
>aska.pl - DNS File/Stream Sender
>geta.pl - DNS File/Stream Receiver
>nomde.pl - Experimental DNS Server
>droute.pl - Reliable DNS Transport for standard input/output
>glance.c - Represents IP addresses as dates
>
>More information about all of these tools can be found in Dan's Black
>Ops DNS 2004 CCC Congress slides:
>http://www.ccc.de/congress/2004/fahrplan/files/297-black-ops-of-dns-slides.pdf

Hmmm. I used to run this version of ozymandns to provide IP-over-DNS
style services, and it was far from stable. It would often crash, drop
connections or chew lots of CPU for no apparent reason. Unless things
have improved substantially since, I would recommend strongly against
adding these to the archive.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews


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

Re: Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools

[Lucas Nussbaum]

On 06/08/08 at 23:17 +0100, Steve McIntyre wrote:
> Jacob wrote:
> >Package: wnpp
> >Severity: wishlist
> >Owner: Jacob Appelbaum <[EMAIL PROTECTED]>
> >
> >
> >* Package name: ozymandns
> >  Version : 0.0.1
> >  Upstream Author : Dan Kaminsky <[EMAIL PROTECTED]>
> >* URL : http://www.doxpara.com/ozymandns_src_0.1.tgz
> >* License : (Currently consulting with upstream for explicit
> >* license)
> >  Programming Lang: (C, Perl)
> >  Description : An experimental DNS server and miscellaneous DNS tools
> >
> >OzymanDNS is a suite of tools for experimenting with DNS. It includes a
> >number of tools:
> >
> >aska.pl - DNS File/Stream Sender
> >geta.pl - DNS File/Stream Receiver
> >nomde.pl - Experimental DNS Server
> >droute.pl - Reliable DNS Transport for standard input/output
> >glance.c - Represents IP addresses as dates
> >
> >More information about all of these tools can be found in Dan's Black
> >Ops DNS 2004 CCC Congress slides:
> >http://www.ccc.de/congress/2004/fahrplan/files/297-black-ops-of-dns-slides.pdf
> 
> Hmmm. I used to run this version of ozymandns to provide IP-over-DNS
> style services, and it was far from stable. It would often crash, drop
> connections or chew lots of CPU for no apparent reason. Unless things
> have improved substantially since, I would recommend strongly against
> adding these to the archive.

Confirmed. And it hasn't been fixed.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Teco Industry is in the business of corn, wheat, paddy, and

[TECO DRYER]

vegetable dr
Sender: "TECO DRYER" <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Thu, 7 Aug 2008 00:08:40 +0300
Message-ID: <[EMAIL PROTECTED]>
X-Priority: 3 (Normal)
Importance: Normal

Teco Industry is in the business of corn, wheat, paddy, and vegetable drying 
machines and the production and marketing of silo & steel construction. Related 
to the machines that our company produce; Teco Industry has the representatives 
in Bulgaria, Albania, Ukraine, Tatarstan, Kazakhstan, Russia, Angola and 
Indonesia. Our partners in these countries are accepted as the leaders in the 
steel industry. The quality of produced machines is approved by international 
standards. Teco is guaranteed by CE and ISO 9001-2000 certificates.

 

Teco also contributes to the national economy by creating jobs in designing, 
project, production, import and export. Teco materializes R&D activities with 
its professional staff. Quality results are presented to the customers during 
the production, import and export.

 

 

Our company takes the leadership of producing and marketing nationally and 
internationally.

For Grain, Oily Seeds, and Pulses:
Silos
Corn and Soybean Drying Machines 
Handling Systems like Bucket Elevator, Chain Conveyor and Helix
Prop Towers and Catwalks for Handling Systems
Unloading Truck Lifts
Industrial Foundations, Steel Construction
 

With the expert staff; we take an important target like ‘’Customer Satisfaction 
and Service Quality’’ and perform service and counseling duties successfully. 






 Contact Us  , Teco Dryer Company is ready for a long partnership with you.

 

 Sales Engineer Erkan AYMAN [EMAIL PROTECTED]


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

Re: projectb users - we want you

[Charles Plessy]

Le Wed, Aug 06, 2008 at 09:13:47PM +0200, Joerg Jaspert a écrit :
> Hi
> 
> as we are currently planning database changes en masse to the projectb,

Hi Jörg,

can you briefly summarise what the projectdb is? I tried a Google search
with "debian projectdb" as a keyword and did not find any relevant
public documentation. Is the change related to the "Ultimate Debian
Database" that is being developped during the Google Summer of Code?

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan


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

Re: Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools

[Clint Adams]

On Thu, Aug 07, 2008 at 12:48:20AM +0200, Lucas Nussbaum wrote:
> Confirmed. And it hasn't been fixed.

That's why I run it in a while loop and find it to be reasonable
functional that way.


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

Re: trying to overwrite ..., which is also in package ...

[Stefano Zacchiroli]

On Wed, Aug 06, 2008 at 11:47:28AM +0200, Vincent Danjean wrote:
> Looking at the description (http://edos.debian.net/missing-conflicts/doc.html)
> I'm not sure weather these tests take into account upgrades.
>
>   So, just for my information, does edos do that ?

Indeed they don't. Actually that tests are only meant to detect
"statically" missing file Conflicts, while the kind of file overwrite
problems which are spotted during package upgrades are more dynamic and
depends on the order in which packages upgraded. Even though there is a
logic followed by apt/dpkg in deciding the order in which perform
package upgrades, that logics is currently not formalized and hence not
used by the current EDOS/Mancoosi tools.

A bit more information about the file overwrite checks, in addition to
those available in the link you posted above, are available in the paper
accompanying the Mancoosi talk at DebConf8. A .pdf of that is available
at http://upsilon.cc/~zack/research/publications/debconf8-mancoosi.pdf,
and also as an attachment to the event in Pentabarf (but I'm not sure if
the latter is publicly available).

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time


signature.asc
Description: Digital signature

Re: edos, mancoosi - Was: Re: trying to overwrite ..., which is also in package ...

[Stefano Zacchiroli]

On Wed, Aug 06, 2008 at 12:01:46PM +0200, Olivier Berger wrote:
> I think it's the purpose of what's coming out of the mancoosi project
> (http://www.mancoosi.org/) which follows edos, IIRC.

Indeed, more generally all the aspect of package upgrades are in the
scope of Mancoosi, while EDOS was more about the distribution side
focusing, among other things, on avoiding broken packages in package
repositories.

> More details for instance in : http://www.mancoosi.org/deliverables/,
> or (in french) in :
> http://www.systematic-paris-region.org/fr/UserFiles/File/GT%20LL/EdosToMancoosi.pdf

I do have an English version of (a slightly modified version of) that
talk, delivered at the University of Lugano a few weeks ago.  If people
are interested I can make it available, just mail me privately if you
are.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time


signature.asc
Description: Digital signature

Re: Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools

[Jacob Appelbaum]

Clint Adams wrote:
> On Thu, Aug 07, 2008 at 12:48:20AM +0200, Lucas Nussbaum wrote:
>> Confirmed. And it hasn't been fixed.
> 
> That's why I run it in a while loop and find it to be reasonable
> functional that way.
> 
> 

I've done just that in a screen session and I've found it to be quite
useful. Screen is probably a bit heavy for the package to depend on. It
is relatively usable in my use cases.

Best,
Jacob


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

Re: Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools

[Jacob Appelbaum]

Lucas Nussbaum wrote:
> On 06/08/08 at 23:17 +0100, Steve McIntyre wrote:
>> Jacob wrote:
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Jacob Appelbaum <[EMAIL PROTECTED]>
>>>
>>>
>>> * Package name: ozymandns
>> Hmmm. I used to run this version of ozymandns to provide IP-over-DNS
>> style services, and it was far from stable. It would often crash, drop
>> connections or chew lots of CPU for no apparent reason. Unless things
>> have improved substantially since, I would recommend strongly against
>> adding these to the archive.
> 
> Confirmed. And it hasn't been fixed.

Hello,

Micah Anderson encouraged me to package this software. We were both
annoyed that it is both very useful and seemingly abandoned software.

I'd agree that ozymandns has an unstable component (specifically
nomde.pl in my experience). However, the file transfer utilities are
just fine as far as I've seen. Have you had any problems with them? Do
you have test cases that crash them?

Despite the sometimes weird behavior of nomde.pl, Ozymandns as a suite
is quite useful. I'm actually using it right now to send this email. :-)

Currently Debian users can only use it as an unmaintained tar.gz
randomly found online. Dan Kaminsky and I spoke about a Debian package.
He seemed happy to have someone, even if it wasn't me, package it up.
This was some time ago but I believe he still feels this way. I've
recently attempted to contact him about licensing issues and hopefully
that will be worked out soon as well...

I've taken the time to integrate a widely used patch, write man pages
and example documentation. I've also created an init.d script. Once I
have finish packaging ozymandns, I hope to find the cause of the
instability issues I've personally experienced.

Best,
Jacob


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

dhclient-script, hooks, and changing the environment

[martin f krafft]

Folks,

having gotten over the rage that caused [0] to be written, I am now
trying to make an informed decision about how netconf should
integrate DHCP hooks. I thus seek your opinion and experience and
would appreciate your help.

dhclient hooks are encouraged by the dhclient-script(8) manpage to
modify the environment and override shell functions to change the
behaviour of dhclient-script. To enable this, dhclient-script
sources them one after the other.

Since netconf isn't written in shell, to support this "feature",
I would have to run each hook from a shell and print, feed back, and
process the environment with the execvp() call. Major hack, major
pain, and I am -><- this close to dumping the "feature".

resolvconf overrides make_resolv_conf(), but resolv.conf will be
handled by dhclient directly anyway, so that very application of
sourcing hooks is being taken care of.

Anything else? Do you know of packages that rely on this
functionality? Do you have scripts of your own which modify the
environment? Would you please be so kind as to explain to me what
they do, and help me figure out whether there isn't a better way for
them?

0. http://madduck.net/blog/2008.08.05:the-dhclient-nightmare/

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
one morning i shot an elephant in my pyjamas.
how he got into my pyjamas i'll never know.
   -- groucho marx


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Bug#494043: ITP: ozymandns -- An experimental DNS server and miscellaneous DNS tools

[Marco d'Itri]

On Aug 07, Jacob Appelbaum <[EMAIL PROTECTED]> wrote:

> Micah Anderson encouraged me to package this software. We were both
> annoyed that it is both very useful and seemingly abandoned software.
What does it provide exactly over the other DNS tunneling packages
available in Debian?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Deprecating (and deactivation) of an archive feature?!

[Adeodato Simó]

* Julien Cristau [Wed, 06 Aug 2008 21:38:00 +0200]:

> On Wed, Aug  6, 2008 at 20:47:50 +0200, Joerg Jaspert wrote:

> > Now, the idea would be to deprecate this feature, used by 8 packages in
> > unstable, dropping complications in the database backend and the pool
> > layout which we would want to avoid.

> Maybe you could tell us what the benefit of dropping this would be (as
> in, what are the changes you allude to, and why can't they work with
> this feature).

I agree this would be useful.

I do think that allowing packages in main to provide binaries in contrib
is useful, so I'd like to hear what the benefits would be if we'd agree
to lose it.

Thanks,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Luke Vibert - Harmonic


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

Re: projectb users - we want you

[Cyril Brulebois]

Charles Plessy <[EMAIL PROTECTED]> (07/08/2008):
> > as we are currently planning database changes en masse to the
> > projectb,
   ^

> I tried a Google search with "debian projectdb" as a keyword
  ^^

Also, you may need to force the search on projectb (rather than project)
by using quotes around that keyword, depending on your search engine.
You'll find some posts on Jörg's blog, which should give you some leads.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: projectb users - we want you

[Joerg Jaspert]

On 11470 March 1977, Charles Plessy wrote:

>> as we are currently planning database changes en masse to the projectb,
> can you briefly summarise what the projectdb is? I tried a Google search
> with "debian projectdb" as a keyword and did not find any relevant
> public documentation. Is the change related to the "Ultimate Debian
> Database" that is being developped during the Google Summer of Code?

As you dont know it - you are for sure no user of it, so not my target.

That aside - its the central dak database keeping the information we (as
in ftp*) need to provide/run the archive. Nothing to do with the UDD.

-- 
bye, Joerg
 [Clint]: I'm convinced zsh users could deal with a keyboard that has 
5 random letters, tab and enter.
 3 random letters :)
 you need anything but tab and perhaps space?
 yes, enter - sometimes you want the completed thing to happen


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

Re: Deprecating (and deactivation) of an archive feature?!

[Stefano Zacchiroli]

On Thu, Aug 07, 2008 at 01:28:49AM +0100, Adeodato Simó wrote:
> I do think that allowing packages in main to provide binaries in contrib
> is useful, so I'd like to hear what the benefits would be if we'd agree
> to lose it.

I have no idea if there are technical benefits in dropping the support
for this. However, I do see a conceptual problem with the current
organization for such a border case.

*If* the directory organization in our mirrors should reflect what is
part of Debian and what is not (and note that recently this assumption
has been challenged), then the current situation is weird at best. We
have source packages located, say, under
/debian/dists/unstable/main/source/ which can possibly generated
binaries belonging to contrib/.

A user can be rightfully puzzled by such a situation: is the _source_
package she is downloading part of Debian or not?

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time


signature.asc
Description: Digital signature

Re: dhclient-script, hooks, and changing the environment

[Brian May]

martin f krafft wrote:

Anything else? Do you know of packages that rely on this
functionality? Do you have scripts of your own which modify the
environment? Would you please be so kind as to explain to me what
they do, and help me figure out whether there isn't a better way for
them?
  
Packages that come to mind that want to alter the environment of it 
parent are:


   * ssh-agent
   * 

I guess you could also write a shell script to a temp file and then 
source that. Not sure if this is any cleaner though.


Brian May


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

Re: projectb users - we want you

[Joerg Jaspert]

> As you dont know it - you are for sure no user of it, so not my target.

And that should have had a :) behind, which some dwarfs did eat.

-- 
bye, Joerg
 Das mit Tolimar ist echt doof.
 Ich find das nicht gut.
 Da richtet man ihm gestern pserver-cvs-Access ein
 und heute kann man's schon wieder loeschen.
 Das war voll sinnlose Arbeit gestern.
(Tolimar kriegte an einem Tag AM, FD und DAM approval sowie Account)


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

Re: dhclient-script, hooks, and changing the environment

[martin f krafft]

also sprach Brian May <[EMAIL PROTECTED]> [2008.08.06.2242 -0300]:
> Packages that come to mind that want to alter the environment of it  
> parent are:
>
>* ssh-agent

You have to eval the output, no?

>* 

*horror* ! :)

Neither of those affect /etc/dhcp3/dhclient-*-hooks.d though...

> I guess you could also write a shell script to a temp file and
> then  source that. Not sure if this is any cleaner though.

The problem is that netconf has no dhclient-script anymore as it
parses dhclient REASONS directly and then proceeds to use e.g. IP
address and router stuff as if it had been gathered from /e/n/i.
Thus, hooks are execvp()'d from netconf directly. If I wanted to
allow hooks to modify the environment, I'd have to execvp()

  sh -c '. the_hook; env | while read line; do echo "ENVIRONMENT:$line'

and then parse that stuff out of stdout, which, to put it mildly, is
ASS. I'd really rather not.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
consciousness: that annoying time between naps.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: dhclient-script, hooks, and changing the environment

[Brian May]

martin f krafft wrote:


The problem is that netconf has no dhclient-script anymore as it
parses dhclient REASONS directly and then proceeds to use e.g. IP
address and router stuff as if it had been gathered from /e/n/i.
Thus, hooks are execvp()'d from netconf directly. If I wanted to
allow hooks to modify the environment, I'd have to execvp()

  sh -c '. the_hook; env | while read line; do echo "ENVIRONMENT:$line'

and then parse that stuff out of stdout, which, to put it mildly, is
ASS. I'd really rather not.
  

sh -c '. the_hook; env | while read line; do echo "ENVIRONMENT:$line"; done > 
/tmp/file'

Still extremely ugly, but at least you don't have to redirect stdout in 
the_hook. Need to do something better for

/tmp/file of course.

How many dhclient scripts actually make use of this "feature" of being 
able to change environment variables?  If it is little used maybe it 
isn't worth the effort in supporting.


Brian May


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

Re: correct definition of localhost?

[Aurelien Jarno]

On Mon, Jul 07, 2008 at 06:05:20PM +0200, Aurelien Jarno wrote:
> Michael Banck a écrit :
> > On Mon, Jul 07, 2008 at 05:49:04AM +0200, Aurelien Jarno wrote:
> >> There is a bug upstream, but marked as invalid:
> >>
> >>   http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980
> >>
> >> According to the upstream developer, there is a rationale for that, but
> >> he never explained it, despite having been asked numerous times.
> > 
> > In his latest reply, the upstream developer said that code got rewritten
> > since, I have not checked their repository though.
> 
> I have just built a version from CVS, and I confirm the bug is fixed.
> However I failed to find the commit(s) which fixed it, and anyway I
> doubt it's a single commit. Therefore I don't think we can backport the
> fix for lenny.
> 
> We can try to use the proposed 2.7 patch instead.

Please open a bug report with severity (at least) important if you
consider we should fix this bug for lenny. If not, the problem will be
fixed when we switch to glibc 2.9.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: dhclient-script, hooks, and changing the environment

[Mike Hommey]

On Wed, Aug 06, 2008 at 11:41:39PM -0300, martin f krafft wrote:
> also sprach Brian May <[EMAIL PROTECTED]> [2008.08.06.2242 -0300]:
> > Packages that come to mind that want to alter the environment of it  
> > parent are:
> >
> >* ssh-agent
> 
> You have to eval the output, no?
> 
> >* 
> 
> *horror* ! :)
> 
> Neither of those affect /etc/dhcp3/dhclient-*-hooks.d though...
> 
> > I guess you could also write a shell script to a temp file and
> > then  source that. Not sure if this is any cleaner though.
> 
> The problem is that netconf has no dhclient-script anymore as it
> parses dhclient REASONS directly and then proceeds to use e.g. IP
> address and router stuff as if it had been gathered from /e/n/i.
> Thus, hooks are execvp()'d from netconf directly. If I wanted to
> allow hooks to modify the environment, I'd have to execvp()
> 
>   sh -c '. the_hook; env | while read line; do echo "ENVIRONMENT:$line'
> 
> and then parse that stuff out of stdout, which, to put it mildly, is
> ASS. I'd really rather not.

Why not open a new fd and then run
sh -c '. the_hook; env >&3' ?

(though the hook script could also be closing and reopening this fd...
using a higher number could be safer)

Mike


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

Come join me on SEO India...

[Chirag Patel]

SEO India: SEO Ahmedabad, SEO India, Search Engine Optimization Company India

Chirag Patel has invited you to join SEO India



Hi Join this community to exchange links easily make SEO contact and Friends 
Easily

Check out SEO India:
http://seosemindia.ning.com/?xgi=j3A0syO

If your email program doesn't recognize the web address above as an active link,
please copy and paste it into your web browser



Members already on SEO India
RIZVAN, kevin, Bhupendra Vasaikar, Raj, Anand



About SEO India...
Search Engine Optimization Company India offers you high keyword ranking for 
your website on top most search engine

29 members
7 discussions



To control which emails you receive on the corner, or to opt-out, go to:
http://seosemindia.ning.com/profiles/profile/emailSettings