Re: congratulations to the X team!!

[Francesco Paolo Lovergine]

On Thu, Jul 14, 2005 at 12:08:00PM +0200, Francesco P. Lovergine wrote:
> On Thu, Jul 14, 2005 at 10:17:24AM +0200, Benjamin Mesing wrote:
> > my congratulation to the team too. However I was not as fortunate as the
> > Sean.
> > 
> 
> Me too, at least on this machine I had to explicitly install
> xserver-xorg to complete the move. BTW, I see the rendering of some ttf
> fonts looks not so good. For instance I used happily this resource:
> 
> XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c-0-iso8859-15
> 
> and the visual quality of that font is now less good.
> 

Ok I can confirm that apt-get dist-upgrade does not remove
xserver-xfree86 and install xserver-xorg. I know that aptitude is the
way to go, but currently its ask for removing a good deal of more packages.
If interested I could replicate on a third box and follup a verbose report
on BTS. I'm not completely pesuaded it is not a transient issue, anyway...

-- 
Francesco P. Lovergine


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

Re: shared library -dev package naming proposal

[Kurt Roeckx]

Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> > > 2. The information of -dev packages depending on other -dev packages
> > > cannot be automatically determined currently; 
> > > it should be possible to obtain a minimal list by analyzing the 
> > > NEEDED field of the objdump output.
> > 
> > Errr, -dev packages generally don't (and shouldn't) depend on other -dev
> > packages.  If you're trying to push the idea that -dev packages should
> > depend on the -dev packages of libraries they depend on- don't.  That's
> > *wrong*, it's the completely wrong approach and should *not* be taken.
> 
> Give me justifications rather than just saying *wrong*,
> because you are giving me an argument that is contrary to 
> current practice in Debian.
> 
> -dev packages do depend on other -dev packages,
> and if they don't work, they are usually filed a serious bug 
> for non-functionality.

Reasons why you need you need to add a build-dependency on libfoo-dev
package:
- You're linking to it
- You're using include files from it.

Simular, if your package is libbar, your lib libbar-dev package needs to
depends on the libfoo-dev packages if:
- Your include files include libfoo's include files.  This is ussually
  something you want to avoid.
- You have a static lib, and people will need to link libfoo if they're
  linking to your package.  I think static libs should be avoided in
  most cases.

An other reason why it's currently done is that some packages link to
packages that only "use" your libbar lib, but also link to libfoo, which
isn't needed.  Isn't not needed because libbar already depends on
libfoo.  This can for instance be the case when using libtool.  The
version of libtool in the archive shouldn't be doing this.

The correct way to fix this is by updating the libtool package, or
whatever that's being used, and not by having -dev packages depend on
other/more -dev packages.  It's just easier to fix this in the short
time, because it only requires one -dev package to be fixed while else
all packages build-depending on it need to be fixed.


Kurt



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

Win 2 Prados with Al-Sayer

[Al Sayer Group]

Title: Al Sayer Group






  




  
  




  
  




  
  




  
  




  
  




  
  




  
  




  
  




  
  




  
  




  
  

  
  
  
http://www.webtech-kw.com
  
  
  
  
  
Unsubscribe this Newsletter
  
  
Delivered by WebTech Co. Kuwait
  

Re: congratulations to the X team!!

[Henning Glawe]

On Fri, Jul 15, 2005 at 08:21:36PM +0200, Klaus Ethgen wrote:
> Well, dosn't work either. It was just a idea that all the packages don't
> get deinstalled and maybe can be used. Also pdl which is needed for
> gimp-perl has wrong dependencies.

I've already uploaded a fixed pdl package, but it didn't compile on all
architectures yet, as x.org seems to be missing on some of them.

-- 
c u
henning


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

Re: skills of developers

[Peter Samuelson]

[Bartosz Fenski]
> That's example:
> http://lists.debian.org/debian-mentors/2005/07/msg00254.html

Wow, that's a disturbing thread!

So, some people honestly don't see a problem with someone taking sole
responsibility for a package with no ability to hack on its source?  At
the very least I'd expect it to be common sense of the most basic sort
that you need at least one comaintainer qualified to extract, read and
write patches.

> In sum. Maybe it's time to create additional positions in Debian
> project?  Maybe something like Packager (with knowledge about Bash
> and Debian Policy), Translator (with knowledge about some particular
> language and English), Helper (with knowledge about Debian in
> general), and finally DEVELOPER which develops software and is able
> to fix it if it's broken.

Your categories don't really make sense to me.  In what situation would
a Packager who is not a Developer be useful?  Since you'd obviously
need a Developer on your maintainer team anyway, would a mere Packager
on the same team really be able to contribute meaningfully?  (I guess
you can take the above as meaning that I'm in favor of requiring
"Developers" to know Debian Policy and how to build packages.  This
stuff isn't rocket science - it's really not much to ask, for people
who already hack on free software.)

The Helper position seems even more useless to me - I don't understand
what a Helper could contribute.  Did you intend this one to encompass
debian-legal and debian-www?

> Developers could be splitted to Python/Perl/C/C++/Java/Mono/and so
> on...

The overhead of handing out these 'certifications' would far outweigh
any advantages I can think of in having them.


signature.asc
Description: Digital signature

\x82\xB1\x82\xF1\x82\xC9\x82\xBF\x82\xCD\x81B18:25:51

[qsduxzj]

\x82\xA8\x94\xE6\x82\xEA\x82\xB3\x82\xDC\x82\xC5\x82\xB7\x81B
\x90\xE6\x93\xFA\x82\xCC\x98b\x91\xE8\x82\xCC\x83T\x83C\x83g\x82\xC5\x82\xB7\x81B

http://www.bluejade.bz/


\x8B\xAD
25351

Re: skills of developers

[Benjamin Mesing]

Hello,

> > You claim that if someone spends just as much time translating Debian as
> > someone else does on packaging software, the first one shouldn't become a
> > DD and the second one does? I disagree firmly.
> 
> Packaging is the essential work and everyone involved into Debian must
> be able to do the basic things. You don't go to military just to sit
> around and do office work - everyone has to go trough basic training.
I disagree. Maintaining the webpages, doing translations and stuff like
this is of equal importance to the project. If you hire a Web Designer
for your software producing company, you don't require him to have
programming abilities?
Thats what division of labour is all about.


> > (and can demonstrate this in a variety of ways, including a debian.org
> > email address). And that you can influence its direction when there's a
> 
> Aha, that's what it is all about. Demonstrate the "beeing a VIP".
No, not VIP. Its about feeling to be a part of the project, its about
being able to "influence its direction when there's a vote up". Would
you ever feel a real citizen of a state if you were not allowed to vote?


> The outcome of the votes mostly affects... whom? Right, the packagers,
> or at least people that know what it is all about. For the same reasons
> Debian policy is not written by lawyers or philosophers.
The outcome affects the project. I think translators, webpage
maintainers and others are part of the project.

Greetings
Ben (who is no Debian Developer himself and hates to do documenting and
translating)


-- 
Please do not sent any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.


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

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Ralf Treinen]

I have a (probably very stupid) question:

On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:

> If one of your packages needs to be transitioned, DO NOT upload it before
> the C++ libraries it depends on have successfully made the transition.

Is there an easy way to find out which of the libraries a package
depends are C++ libraries, and which are not?

-Ralf.
-- 


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

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Stephen Gran]

This one time, at band camp, Ralf Treinen said:
> I have a (probably very stupid) question:
> 
> On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:
> 
> > If one of your packages needs to be transitioned, DO NOT upload it before
> > the C++ libraries it depends on have successfully made the transition.
> 
> Is there an easy way to find out which of the libraries a package
> depends are C++ libraries, and which are not?

grep'ing for Depends: libstdc++ would probably do it (although I have
recently found that some, like libgmp3, only Recommend: libstdc++ as it
is a c library with c++ bindings).
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#318605: ITP: asterisk-prompt-it -- Italian voice prompts for the Asterisk PBX

[Mark Purcell]

Package: wnpp
Severity: wishlist
Owner: Mark Purcell <[EMAIL PROTECTED]>

* Package name: asterisk-prompt-it
  Version : 20041110
  Upstream Author : Marco Menardi <[EMAIL PROTECTED]>
* URL : 
ftp://213.156.62.146/pub/linux/asterisk/sounds/it/it_mm_sounds_20041110.tar.gz
* License : LGPL
  Description : Italian voice prompts for the Asterisk PBX

 These are Italian voice prompts for the Asterisk PBX, courtesy of
 Marco Menardi
 .
 You need this package if you intend to run Asterisk and wish to
 support Italian callers.
 .
 Traduzione dei file sonori di Asterisk by Marco Menardi ? 2004-11-10
 .
 Qui riporto il nome file, il messaggio in italiano e, fra parentesi,
 l'originale in inglese dei
 ?suoni? di asterisk CVS. Il testo inglese si ricava dal file
 ?/usr/src/asterisk/sounds.txt?
 Per funzionare correttamente hanno bisogno anche di un adattamento del
 software asterisk, attualmente in corso di sviluppo e/o integrazione
 Devono venir modificate le applicazioni:

Tzafrir. Provided you are happy I was just going to use your packages,
http://tzafrir.org.il/rapid108/unstable/
s/Italic/Italian/ and modify the copyright and package description to 
reflect above. Sign and then upload to unstable.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


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

Re: skills of developers

[Torsten Landschoff]

Hi *,

What kind of discussion is this? We can't effort more bureaucrazy (typo
intended) in the project. Let the people doing the work do the work
instead of first measuring their ability. If you are not able to
maintain a package basically you wont. Or you wont for long as somebody
will take over. And critical packages are assigned anyway so why bother
that much?

Apart from that I'd say that everybody doing relevant work for the
project should be able to get the developer status. It's not about being
able to write C, C++ or something. It's about being important to the
project in any way.

Imagine Christian Perrier would just do translations - don't you think
he would be an important part of the project anyway?

Greetings

Torsten



signature.asc
Description: Digital signature

[RFC] Auto-Accept libs with just changed SONAME?

[Torsten Landschoff]

Hi *, 

During one of the talks of Debconf (I think it was about shared library
packaging) there was a complaint that tracking upstreams SONAME changes
means that your library package will end up in NEW each time it really
changed. 

I'd like to suggest fixing the scripts to only flag packages as new if
it isn't obviously just one  of these SONAME changes. As I don't really
know katie etc. I don't know how complicated this is so I don't just
start to work on it know but ask if it would make sense to others.


Basically a library package should be regarded as an update if

a) the package is already in the archive
  orb) the package name starts with lib and matches a known package 
up to a "-"
and the remainder is just -[0-9]+-[0-9]+ after stripping known
suffixes (like c102 etc.)

Comments?

Torsten


signature.asc
Description: Digital signature

Re: Procedure reminders on updating a lib package for a C++ ABI change

[David Pashley]

On Jul 16, 2005 at 14:27, Stephen Gran praised the llamas by saying:
> This one time, at band camp, Ralf Treinen said:
> > I have a (probably very stupid) question:
> > 
> > On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:
> > 
> > > If one of your packages needs to be transitioned, DO NOT upload it before
> > > the C++ libraries it depends on have successfully made the transition.
> > 
> > Is there an easy way to find out which of the libraries a package
> > depends are C++ libraries, and which are not?
> 
> grep'ing for Depends: libstdc++ would probably do it (although I have
> recently found that some, like libgmp3, only Recommend: libstdc++ as it
> is a c library with c++ bindings).

Shouldn't the C++ bindings be split out and depend on libgmp3 and
libstdc++?


-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


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

Re: Dependency problems with Xorg

[Harald Dunkel]

Goswin von Brederlow wrote:
> yes
> 
> welcome to the c++ abi transition
> 
> 
Maybe this has been suggested before, but...

Probably more C++ abi changes will follow. To support a
smooth migration I would like to suggest to create empty
packages describing the C++ abis.

A package maintainer could add the C++ abi package to the
dependency list. When a new C++ abi gets introduced, and
the first packages with a dependency to the new abi package
appear, then these packages are automagically put on hold
till all packages in the whole dependency chain have been
migrated.

Surely the package name or the version number are the wrong
place to describe the C++ abi.


Just an idea. Regards

Harri


signature.asc
Description: OpenPGP digital signature

Re: Procedure reminders on updating a lib package for a C++ ABI change

[René van Bevern]

On 16.07.05, David Pashley wrote:
> On Jul 16, 2005 at 14:27, Stephen Gran praised the llamas by saying:
> > libgmp3, only Recommend: libstdc++ as it is a c library with c++ bindings
> Shouldn't the C++ bindings be split out and depend on libgmp3 and
> libstdc++?

This has been done in course of the C++ transition.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311610

René van Bevern,
  http://progn.org



pgpCIclJg26rS.pgp
Description: PGP signature

Re: [RFC] Auto-Accept libs with just changed SONAME?

[Joerg Jaspert]

On 10352 March 1977, Torsten Landschoff wrote:

> During one of the talks of Debconf (I think it was about shared library
> packaging) there was a complaint that tracking upstreams SONAME changes
> means that your library package will end up in NEW each time it really
> changed. 

And? Hows that bad?

> I'd like to suggest fixing the scripts to only flag packages as new if
> it isn't obviously just one  of these SONAME changes. As I don't really
> know katie etc. I don't know how complicated this is so I don't just
> start to work on it know but ask if it would make sense to others.

I vote against it.
Nice example just arrived yesterday: "Just" an soname change,
maintainer didnt fix his scripts, no files installed in .debs. Simple,
nice, example against automated addition of files.

-- 
bye Joerg


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

Re: New gimp-print packages in experimental

[Andrew Lau]

On Sat, Jul 02, 2005 at 03:24:18PM +0100, Roger Leigh wrote:
> gimp-print (renamed to gutenprint) is near its 5.0 release.  I've
> uploaded a prerelease to experimental, which is also available here:

Hi Roger,

I need to rebuild cinepaint 0.19.1-1 due to the CXX transition currently
in progress, but I'd like to be able to ship with printing support this
time around. Could you please update me on how your progress towards
uploading gutenprint to unstable is coming along?

Cheers,
Andrew "Netsnipe" Lau

-- 
---
 Andrew "Netsnipe" Lau  
 Debian GNU/Linux Maintainer & Computer Science, UNSW
 -
  "Nobody expects the Debian Inquisition!
 Our two weapons are fear and surprise...and ruthless efficiency!"
---


signature.asc
Description: Digital signature

Re: Dependency problems with Xorg

[Goswin von Brederlow]

Harald Dunkel <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
>> yes
>> 
>> welcome to the c++ abi transition
>> 
>> 
> Maybe this has been suggested before, but...
>
> Probably more C++ abi changes will follow. To support a
> smooth migration I would like to suggest to create empty
> packages describing the C++ abis.
>
> A package maintainer could add the C++ abi package to the
> dependency list. When a new C++ abi gets introduced, and
> the first packages with a dependency to the new abi package
> appear, then these packages are automagically put on hold
> till all packages in the whole dependency chain have been
> migrated.
>
> Surely the package name or the version number are the wrong
> place to describe the C++ abi.
>
>
> Just an idea. Regards
>
> Harri

A single C++-ABI package would just mean that all c++ packages are
kept back (or removed) from the very start of the c++ transition up to
the very end. There will be a lot of packages at the end of the
dependency chains that you don't have installed and that will take
long to fix. Do you realy want to wait for every last one to get
fixed?

Even worse you couldn't install g++-3.3 and g++-3.4/4.0 in parallel as
the libstdc++s would depend on conflicting C++-ABI packages.


To be save as apt-get user just use "dist-upgrade" as that won't
remove package and selectively use "install " when you think
something is finished with its transition. Aptitude should be
intelligent enought not to remove non-automatic packages to upgrade
automatic ones. But I'm not sure about that.

MfG
Goswin


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

Re: [RFC] Auto-Accept libs with just changed SONAME?

[Torsten Landschoff]

On Sat, Jul 16, 2005 at 05:22:04PM +0200, Joerg Jaspert wrote:
 
> And? Hows that bad?

It means that volunteers have to spend time on this. In any case. And
maintainer has to wait etc. 

I wonder why we don't automate more stuff in Debian. After all we have
all the abilities to do it.

> > I'd like to suggest fixing the scripts to only flag packages as new if
> > it isn't obviously just one  of these SONAME changes. As I don't really
> > know katie etc. I don't know how complicated this is so I don't just
> > start to work on it know but ask if it would make sense to others.
> 
> I vote against it.
> Nice example just arrived yesterday: "Just" an soname change,
> maintainer didnt fix his scripts, no files installed in .debs. Simple,
> nice, example against automated addition of files.
 
Great. I am not trying to prove that this is better in all cases. We are
talking about the overall case. With your argument everything should go
into new and be checked by ftp admins. After all I could break the new
package even without any upstream change. So better put everything into
NEW and have the ftp masters check. 

Silly, isn't it?

Greetings

Torsten


signature.asc
Description: Digital signature

Bug#318618: ITP: patchage -- modular patch bay for Jack audio and Alsa Midi

[Paul Brossier]

Package: wnpp
Severity: wishlist
Owner: Paul Brossier <[EMAIL PROTECTED]>

* Package name: patchage
  Version : 0.2.0
  Upstream Author : Dave Robillard <[EMAIL PROTECTED]>
* URL : http://www.scs.carleton.ca/~drobilla/patchage/
* License : GPL
  Description : modular patch bay for Jack audio and Alsa Midi

 Patchage provides a graphical interface to connect jack and midi inputs
 and outputs. Each application is presented as one box with inputs on
 the left and output on the right. Boxes can be moved around and
 arranged to have a clear display of the current setup.
 .
  Homepage: http://www.scs.carleton.ca/~drobilla/patchage/


It's funny how hard it can be to describe textually a simple screenshot:
http://www.scs.carleton.ca/~drobilla/patchage/patchage-screenshot.png

tchüß, piem

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-rc5-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


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

unsubscribe

[siva m]

On 7/16/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> As a result of some questions on IRC and some ill-timed uploads that I've
> seen, I think it would be a good idea to highlight a couple of important
> points from Matthias's transition plan for the benefit of library
> maintainers and would-be NMUers:
> 
> The library package renames, libfoo1 -> libfoo1c2, libfoo1c102 -> libfoo1c2,
> or libfoo1c102 -> libfoo1, are done because there is an ABI change *without
> an upstream soname change*.  Since there is no soname change, the files
> installed by the renamed package will also not change -- which means, just
> like for any other packages with overlapping files, you *must* conflict with
> the previous library package name.  You must *not* add a Provides: libfoo1
> or Provides: libfoo1c102 to the new package; this transition is happening
> because of an ABI transition, which means the new package will NOT provide
> the same interface as the old one, and setting Provides will lead apt to
> give your users broken package combinations.
> 
> If one of your packages needs to be transitioned, DO NOT upload it before
> the C++ libraries it depends on have successfully made the transition.
> Barring exceptional buildd delays, you should wait until your
> build-dependencies have been rebuilt for g++ 4.0 on *all* architectures
> before uploading your package.  Otherwise, you'll cause unnecessary churn on
> the buildds, and it will take *longer* for your package to get built
> everywhere.  Being impatient now will mean a longer wait later.  A useful
> interface for tracking the status of a package across architectures can be
> found at .
> 
> If any of what I've said above surprises you, then you should go back and
> read the complete email about the transition plan[1] before uploading
> anything.  If you have questions, /ask/.  Five minutes asking/answering a
> question now can easily save us weeks of fighting to get a package back into
> releasable shape.
> 
> Also, for those who aren't aware, the new xorg packages now in unstable are
> also implicated in the C++ transition, because libGLU is implemented in C++.
> Particularly if you have packages that are involved in other transitions
> that are happening right now, it may not necessarily be a good idea to
> rebuild against xorg just yet unless you're already part of the C++
> transition.  If you do, your package will also get tangled in the same C++
> transition.  This has unfortunately already happened with GNOME, because of
> a maintainer who was in a hurry to update his build dependencies for xorg;
> all of GNOME 2.10 is now held out of testing until xorg is also ready to go
> in, even though xorg has so far only been built successfully on 4/11
> architectures.  In effect, this means all of the large etch transitions are
> now hooked together, but if you have other packages that aren't yet part of
> the tangle, ask before you upload and maybe you'll save yourself some
> trouble.
> 
> Cheers,
> --
> Steve Langasek
> postmodern programmer
> 
> [1] http://lists.debian.org/debian-devel-announce/2005/07/msg1.html
> 
> 
> BodyID:17829889.2.n.logpart (stored separately)
> 
>

Re: [RFC] Auto-Accept libs with just changed SONAME?

[Frank Lichtenheld]

On Sat, Jul 16, 2005 at 05:46:51PM +0200, Torsten Landschoff wrote:
> Great. I am not trying to prove that this is better in all cases. We are
> talking about the overall case. With your argument everything should go
> into new and be checked by ftp admins. After all I could break the new
> package even without any upstream change. So better put everything into
> NEW and have the ftp masters check. 

Shared libraries are often a special case as fixing a breakage that
occoured in one of them can often mean having to fix lots and lots of
packages that depend on them.

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Information about Adore Softphone

[Banoj Tripathy]

Dear Sir/Madam,

Introducing  Adoreinfotech Pvt. Ltd., Company is one of the fastest growing
VOIP Solution Provider.

Our solution includes Softphone, Billing solution and complete PC2Phone
system.

I would like to provide you the information about our Softphone

For more information about our softphone, please check the link :

 http://www.adoresoftphone.com

 To download our demo softphone, please use  the link below:

For  Exe  version of  demo softphone:
http://www.adoresoftphone.com/adoresoftphone.exe

For  Setup  version of  demo softphone:
http://www.adoresoftphone.com/adoresoftphonesetup.exe

For  Zip  version of  demo softphone :
http://www.adoresoftphone.com/adoresoftphone.zip


Please Enter  in the login

 SIP Ip/ Domain:  Your Sip Server IP/ Domain

 Account PIN :  Enter User Id

 Password :   Enter Password

 Click on  Login.

 Dial the no and call.


 The softphone can be customized with your skin. You can
 provide the skin or we can develop the skin as per your
 specification.

 For more information about skins, please check the link :

 http://www.adoresoftphone.com/Skins.html


 Here are the features and benefits of our SIP Dialer:

 Features:
 
 * Customized Skin Interfaces
 * Call Timer
 * Display Balance
  * Last Number Redial
 * Local Signalization (Dial tone, busy, ring back, etc.) for user comfort
 * Mute
 * Touch-Tones
 * Address Book
 * Microphone Volume Control
 * Speaker Volume Control


Benefits:
 
 * Use Microsoft g723.1 codec
 * Small Application
 * Works with any Full-Duplex sound card
 * USB handset and headset support.
 * Works well on all versions of Microsoft Windows (Like 95, 98, 98SE,
 Millennium, NT4, 2000, XP, 2003)
 * NAT/Firewall support, stable SIP, RTP ports
 * Specify NAT IP to be written in SIP messages
 * Auto-Configuration of settings for easy deployment
 * STUN support for NAT detection and classification
 * Configuration Wizard
 * Uses New RFC 3261 compliant stack


Here are the  different version of Adore softphone.

 1. Lite.- It has the basic feature as same as Demo softphone.It would cost
 you   $499 USD with customization of  skin and your logo for unlimited
 users.
 http://www.adoresoftphone.com/Softphone1.html


2.Professional- In addition of the features of LIte,It  has the following
 extra feature-
a. Display account balance on the softphone.
 It would cost you   $999 USD with customization of  skin and your logo for
 unlimited users.
 http://www.adoresoftphone.com/Softphone2.html


 3.Advanced.-In addition of the features of LIte,It  has the following
extra feature-
 a. Display account balance on the softphone
 b.Display Credit account time count down
 c. Invalid PIn
 d.Expired Pin.
 e.Insufficient fund
 It would cost you   $1499 USD with customization of  skin and your logo
 for
 unlimited users.
 http://www.adoresoftphone.com/Softphone3.html

If you have any queries, please let me know. I would
be happy to assist you.

Looking forward to do business with you



Thanks and Regards,

Banoj  Tripathy
Senior Manager
International Sales
Adore Infotech Pvt. Ltd.
Phone: +91-11-517248-91/92/94
Fax: +91-11-51724895
Email: [EMAIL PROTECTED]
: [EMAIL PROTECTED]
Web site:  http://www.adoreinfotech.com
http://www.adoresoftphone.com


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

Re: Dependency problems with Xorg

[Harald Dunkel]

Goswin von Brederlow wrote:
> 
> A single C++-ABI package would just mean that all c++ packages are
> kept back (or removed) from the very start of the c++ transition up to
> the very end. There will be a lot of packages at the end of the
> dependency chains that you don't have installed and that will take
> long to fix. Do you realy want to wait for every last one to get
> fixed?
> 

The dependencies are verified just for the installed packages,
plus the newly selected, minus the packages to be deinstalled,
AFAIK. To avoid waiting I could remove packages sticking to the
old abi.

> Even worse you couldn't install g++-3.3 and g++-3.4/4.0 in parallel as
> the libstdc++s would depend on conflicting C++-ABI packages.
> 

But the ABIs conflict, anyway, regardless whether there is
yet another package or not. A clean way to create packages
for the new abi is to debootstrap a new chroot without
references to the old abi, and use this environment for
building and testing.

But I can follow your argument. Dpkg should allow installing
different C++ abis on the same machine. Only within each
dependency chain the abi version number must be unique, so
it should become some kind of package attribute. This would
allow dpkg to verify the abi version.

I just want to avoid that somebody else breaks the dependencies
of my package by dropping the old name and introducing a new one
for the same library, just because we changed a low level
interface that usually should be transparent to everybody.


Regards

Harri


signature.asc
Description: OpenPGP digital signature

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Marcelo E. Magallon]

On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:

 > Also, for those who aren't aware, the new xorg packages now in
 > unstable are also implicated in the C++ transition, because libGLU is
 > implemented in C++.

 Keyword: implemented.

 All of GLU's interfaces are C, not C++, so "transitioning" libGLU is
 ill-advised at best.

 What I mean here is that no package should:

a. Have an exclusive dependency on libglu1-xorg
b. Have to wait for libglu1-xorg to enter etch
c. Be trainsitioned because of libglu1-xorg

 libglu1-xorg reads:

Replaces: libglu1c2, libglu1, libutahglx1, mesag3 (<< 5.0.0-1),
xlibmesa3 (<< 4.2.1-5), xlibmesa3-glu, xlibmesa-glu
Provides: libglu1c2

 the provides is there in order to allow for other packages to provide
 libGLU, which is nice, thank you so much, but broken.

 Are you aware of a situation that needs this or are you doing this
 "just in case"?  I have tried several GLU-using C++ and libraries
 compiled with g++ 3.3 with the binary provided by libglu1-xorg and they
 are working fine.  I have also compiled programs against libglu1-xorg's
 libGLU and they run fine with other libGLUs compiled with gcc 3.3.

 Marcelo


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

Re: New gimp-print packages in experimental

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Lau <[EMAIL PROTECTED]> writes:

> On Sat, Jul 02, 2005 at 03:24:18PM +0100, Roger Leigh wrote:
>> gimp-print (renamed to gutenprint) is near its 5.0 release.  I've
>> uploaded a prerelease to experimental, which is also available here:
>
> Hi Roger,
>
> I need to rebuild cinepaint 0.19.1-1 due to the CXX transition currently
> in progress, but I'd like to be able to ship with printing support this
> time around. Could you please update me on how your progress towards
> uploading gutenprint to unstable is coming along?

I'm just building a new CVS pre-release snapshot.  It should be in
unstable tomorrow with luck (and more testing).  I haven't had any
reports about problems with the experimental packages, so they should
be OK for unstable.

BTW, there's a new list, [EMAIL PROTECTED], for
discussion of all printing-related stuff.  You might like to join.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFC2WW5VcFcaSW/uEgRAsCSAJ4q80WDUhOcvd4bDnPgQ9WFA/V7vgCfcqTh
GEZj9CM6yDLyhh6Uteu6wYk=
=1EWs
-END PGP SIGNATURE-


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

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Steve Langasek]

On Sat, Jul 16, 2005 at 12:00:12PM -0600, Marcelo E. Magallon wrote:
> On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:

>  > Also, for those who aren't aware, the new xorg packages now in
>  > unstable are also implicated in the C++ transition, because libGLU is
>  > implemented in C++.

>  Keyword: implemented.

>  All of GLU's interfaces are C, not C++, so "transitioning" libGLU is
>  ill-advised at best.

>  What I mean here is that no package should:

> a. Have an exclusive dependency on libglu1-xorg
> b. Have to wait for libglu1-xorg to enter etch
> c. Be trainsitioned because of libglu1-xorg

>  libglu1-xorg reads:

> Replaces: libglu1c2, libglu1, libutahglx1, mesag3 (<< 5.0.0-1),
> xlibmesa3 (<< 4.2.1-5), xlibmesa3-glu, xlibmesa-glu
> Provides: libglu1c2

>  the provides is there in order to allow for other packages to provide
>  libGLU, which is nice, thank you so much, but broken.

>  Are you aware of a situation that needs this or are you doing this
>  "just in case"?  I have tried several GLU-using C++ and libraries
>  compiled with g++ 3.3 with the binary provided by libglu1-xorg and they
>  are working fine.  I have also compiled programs against libglu1-xorg's
>  libGLU and they run fine with other libGLUs compiled with gcc 3.3.

Oh, ugh.  I think the XSF was essentially following Ubuntu's lead here; no
one realized, or thought to check, that the C++ bits weren't exported as
part of the ABI.

David, do you want me to put together a patch that updates the
Provides/Conflicts of libglu1-xorg appropriately?  (Might as well keep the
name change now that it's been done, I think.)

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Steve Langasek]

On Sat, Jul 16, 2005 at 02:44:03PM +0200, Ralf Treinen wrote:
> I have a (probably very stupid) question:

> On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:

> > If one of your packages needs to be transitioned, DO NOT upload it before
> > the C++ libraries it depends on have successfully made the transition.

> Is there an easy way to find out which of the libraries a package
> depends are C++ libraries, and which are not?

grepping for libstdc++ in the deps is usually a good indicator, although
apparently that will cause false-positives *and* false-negatives. :/  You
could also try grepping for '::' in the -dev package's headers, which may be
more reliable. :)

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Marcelo E. Magallon]

On Sat, Jul 16, 2005 at 03:24:50PM -0700, Steve Langasek wrote:

 > Oh, ugh.  I think the XSF was essentially following Ubuntu's lead
 > here; no one realized, or thought to check, that the C++ bits weren't
 > exported as part of the ABI.

 Ah... that was my guess...

 > David, do you want me to put together a patch that updates the
 > Provides/Conflicts of libglu1-xorg appropriately?  (Might as well
 > keep the name change now that it's been done, I think.)

 The package name is not really a problem (libglu1-xorg is fine).  Just
 the "Provides" needs to be fixed and set back to libglu1.

 If someone knows of a case where this breaks, please speak up now.

 Thanks,

-- 
Marcelo


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

Re: aspell dictionary packages fail to build

[Matt Kraai]

On Fri, Jul 15, 2005 at 05:01:03PM +0900, Junichi Uekawa wrote:
> > The aspell dictionary packages build-depend on aspell-bin (>> 0.60).
> > aspell-bin is now a virtual package provided by aspell, but virtual
> > packages cannot be versioned, so these build-dependency cannot be
> > satisfied.
> > 
> > There are fifteen such packages:
> 
> I'd see a benefit in filing mail beforehand for a change, but 
> after-the-fact, I have an impression that it's better to 
> file bugs on the packages since it's easier to track the problem that way.
> 
> Unless there is a chance of reintroducing aspell-bin package, 
> that should probably be the case.
> 
> I think this is the call of aspell maintainer.

Brian, are you planning to reintroduce the aspell-bin package or
should I file bugs against the packages that fail to build?

-- 
Matt


signature.asc
Description: Digital signature

Re: Procedure reminders on updating a lib package for a C++ ABI change

[David Nusinow]

On Sat, Jul 16, 2005 at 05:09:28PM -0600, Marcelo E. Magallon wrote:
> On Sat, Jul 16, 2005 at 03:24:50PM -0700, Steve Langasek wrote:
> 
>  > Oh, ugh.  I think the XSF was essentially following Ubuntu's lead
>  > here; no one realized, or thought to check, that the C++ bits weren't
>  > exported as part of the ABI.
> 
>  Ah... that was my guess...
> 
>  > David, do you want me to put together a patch that updates the
>  > Provides/Conflicts of libglu1-xorg appropriately?  (Might as well
>  > keep the name change now that it's been done, I think.)
> 
>  The package name is not really a problem (libglu1-xorg is fine).  Just
>  the "Provides" needs to be fixed and set back to libglu1.
> 
>  If someone knows of a case where this breaks, please speak up now.

I'll fix this in the next upload. Thanks for calling it to my attention.

 - David Nusinow


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

Re: unreproducable bugs

[Thomas Bushnell BSG]

Rich Walker <[EMAIL PROTECTED]> writes:

> Yes, to rely on 1300 developers to all think of your cunning method of
> solving a problem clearly makes sense. After all, to *write down* a
> technique that solves the problem, and make it available to all of them
> would stilt their creativity, hinder their intellect, and prevent the
> development of a consistent style!

If you want to write down a technique and recommend it to your fellow
developers, please, by all means, do so.

That's a far cry different from someone wanting to enforce a
requirement.


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

Summary about your internet service

[Jones B. Elbert]

How are you,

Does your internet speed seem slower than normal?

Our cheap hardware speeds it up! 

Our website : check4direct.com

To get taken off, add /r to the domain above.

Thank you,
Jones B. Elbert
[EMAIL PROTECTED]

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sat, Jul 16, 2005 at 02:44:03PM +0200, Ralf Treinen wrote:
>> I have a (probably very stupid) question:
>
>> On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:
>
>> > If one of your packages needs to be transitioned, DO NOT upload it before
>> > the C++ libraries it depends on have successfully made the transition.
>
>> Is there an easy way to find out which of the libraries a package
>> depends are C++ libraries, and which are not?
>
> grepping for libstdc++ in the deps is usually a good indicator, although
> apparently that will cause false-positives *and* false-negatives. :/  You
> could also try grepping for '::' in the -dev package's headers, which may be
> more reliable. :)

The grep would catch cases where c++ is used but not exported. See the
libGLU stroy in this thread for an example. I think the libstd++ false
positives would be caused by the same.

MfG
Goswin


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

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Steve Langasek]

On Sun, Jul 17, 2005 at 06:22:21AM +0200, Goswin von Brederlow wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:

> > On Sat, Jul 16, 2005 at 02:44:03PM +0200, Ralf Treinen wrote:
> >> I have a (probably very stupid) question:

> >> On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:

> >> > If one of your packages needs to be transitioned, DO NOT upload it before
> >> > the C++ libraries it depends on have successfully made the transition.

> >> Is there an easy way to find out which of the libraries a package
> >> depends are C++ libraries, and which are not?

> > grepping for libstdc++ in the deps is usually a good indicator, although
> > apparently that will cause false-positives *and* false-negatives. :/  You
> > could also try grepping for '::' in the -dev package's headers, which may be
> > more reliable. :)

> The grep would catch cases where c++ is used but not exported. See the
> libGLU stroy in this thread for an example. I think the libstd++ false
> positives would be caused by the same.

$ grep :: /usr/X11R6/include/GL/glu.h 
$

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: aspell dictionary packages fail to build

[Goswin von Brederlow]

Matt Kraai <[EMAIL PROTECTED]> writes:

> On Fri, Jul 15, 2005 at 05:01:03PM +0900, Junichi Uekawa wrote:
>> > The aspell dictionary packages build-depend on aspell-bin (>> 0.60).
>> > aspell-bin is now a virtual package provided by aspell, but virtual
>> > packages cannot be versioned, so these build-dependency cannot be
>> > satisfied.
>> > 
>> > There are fifteen such packages:
>> 
>> I'd see a benefit in filing mail beforehand for a change, but 
>> after-the-fact, I have an impression that it's better to 
>> file bugs on the packages since it's easier to track the problem that way.
>> 
>> Unless there is a chance of reintroducing aspell-bin package, 
>> that should probably be the case.
>> 
>> I think this is the call of aspell maintainer.
>
> Brian, are you planning to reintroduce the aspell-bin package or
> should I file bugs against the packages that fail to build?
>
> -- 
> Matt

And could someone please please please fix the current aspell first:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=31

It is realy pointless fixing and uploading anything with Build-Depends
on aspell as long as it is uninstallable.

MfG
Goswin


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

Re: Dependency problems with Xorg

[Goswin von Brederlow]

Harald Dunkel <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow wrote:
>> 
>> A single C++-ABI package would just mean that all c++ packages are
>> kept back (or removed) from the very start of the c++ transition up to
>> the very end. There will be a lot of packages at the end of the
>> dependency chains that you don't have installed and that will take
>> long to fix. Do you realy want to wait for every last one to get
>> fixed?
>> 
>
> The dependencies are verified just for the installed packages,
> plus the newly selected, minus the packages to be deinstalled,
> AFAIK. To avoid waiting I could remove packages sticking to the
> old abi.

Yes. But you can only have packages of the old ABI OR of the new ABI
installed. With the current way you can have packages of both abis
matched if their depends chains don't overlap.

E.g. you can install a apt compiled with g++-4.0 without kicking out
every other c++ lib.

>> Even worse you couldn't install g++-3.3 and g++-3.4/4.0 in parallel as
>> the libstdc++s would depend on conflicting C++-ABI packages.
>> 
>
> But the ABIs conflict, anyway, regardless whether there is
> yet another package or not. A clean way to create packages
> for the new abi is to debootstrap a new chroot without
> references to the old abi, and use this environment for
> building and testing.
>
> But I can follow your argument. Dpkg should allow installing
> different C++ abis on the same machine. Only within each
> dependency chain the abi version number must be unique, so
> it should become some kind of package attribute. This would
> allow dpkg to verify the abi version.

And that is what the c102 / c2 is about. :)

Say every package provides libfoobar-c++abi2 that would mean you would
double the depends of every c++ package. Vou need versioned depends on
libs and provides can't be versioned. So you need to depend on both
the lib and the abi. Doesn't appending c2 sound better?

> I just want to avoid that somebody else breaks the dependencies
> of my package by dropping the old name and introducing a new one
> for the same library, just because we changed a low level
> interface that usually should be transparent to everybody.

The break you get anyway. If the library provides a different c++ abi
dpkg must not allow it to be used for your old package, no matter how
you implement this.

Hey, lets hope this is the last C++ transition ever. At least until
g++ 4.1 :)

> Regards
>
> Harri

MfG
Goswin


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

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sun, Jul 17, 2005 at 06:22:21AM +0200, Goswin von Brederlow wrote:
>> Steve Langasek <[EMAIL PROTECTED]> writes:
>
>> > On Sat, Jul 16, 2005 at 02:44:03PM +0200, Ralf Treinen wrote:
>> >> I have a (probably very stupid) question:
>
>> >> On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:
>
>> >> > If one of your packages needs to be transitioned, DO NOT upload it 
>> >> > before
>> >> > the C++ libraries it depends on have successfully made the transition.
>
>> >> Is there an easy way to find out which of the libraries a package
>> >> depends are C++ libraries, and which are not?
>
>> > grepping for libstdc++ in the deps is usually a good indicator, although
>> > apparently that will cause false-positives *and* false-negatives. :/  You
>> > could also try grepping for '::' in the -dev package's headers, which may 
>> > be
>> > more reliable. :)
>
>> The grep would catch cases where c++ is used but not exported. See the
>> libGLU stroy in this thread for an example. I think the libstd++ false
>> positives would be caused by the same.
>
> $ grep :: /usr/X11R6/include/GL/glu.h 
> $

Oh, right. The -dev package shouldn't contain internal headers with
c++ stuff. Sorry.

MfG
Goswin


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

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Matthias Klose]

Ralf Treinen writes:
> I have a (probably very stupid) question:
> 
> On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:
> 
> > If one of your packages needs to be transitioned, DO NOT upload it before
> > the C++ libraries it depends on have successfully made the transition.
> 
> Is there an easy way to find out which of the libraries a package
> depends are C++ libraries, and which are not?

scanning all packages, which depend on libstdc++5, for packages with a
shlibs file. that doesn't catch library packages not linking to
libstdc++, or not building shared libraries. For these, we propose
adding c++abi2-dev to the build depends to identify the dependency on
the C++ ABI.


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

Re: Procedure reminders on updating a lib package for a C++ ABI change

[Matthias Klose]

David Pashley writes:
> On Jul 16, 2005 at 14:27, Stephen Gran praised the llamas by saying:
> > This one time, at band camp, Ralf Treinen said:
> > > I have a (probably very stupid) question:
> > > 
> > > On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:
> > > 
> > > > If one of your packages needs to be transitioned, DO NOT upload it 
> > > > before
> > > > the C++ libraries it depends on have successfully made the transition.
> > > 
> > > Is there an easy way to find out which of the libraries a package
> > > depends are C++ libraries, and which are not?
> > 
> > grep'ing for Depends: libstdc++ would probably do it (although I have
> > recently found that some, like libgmp3, only Recommend: libstdc++ as it
> > is a c library with c++ bindings).
> 
> Shouldn't the C++ bindings be split out and depend on libgmp3 and
> libstdc++?

The already are split out.


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