rakesh deulkar wants to chat

[rakesh deulkar]

I've been using Google Talk and thought you might like to try it out.
We can use it to call each other for free over the internet. Here's an
invitation to download Google Talk. Give it a try!

---

rakesh deulkar wants to stay in better touch using some of Google's coolest new
products.

If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-13c846ccf4-88bc8e6951-661138a2001e97e0
You'll need to click this link to be able to chat with rakesh deulkar.

To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with rakesh deulkar, visit:
http://mail.google.com/mail/a-13c846ccf4-88bc8e6951-428858c603

Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
  emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
  that are relevant to the content of your messages

All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:

http://www.google.com/talk/

Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
  client

Gmail and Google Talk are still in beta. We're working hard to add new features
and make improvements, so we might also ask for your comments and suggestions
periodically. We appreciate your help in making our products even better!

Thanks,
The Google Team

To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html

(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).


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

Re: Amarok build-dep failure

[Ritesh Raj Sarraf]

On Tuesday 22 January 2008, Modestas Vainius wrote:
> No, pbuilder/cowbuilder is able to satisfy build dependencies. I think it's
> rather that build dependences cannot be satisfied _in your environment_.
> You do have bits of KDE4 installed, don't you? You can run:
>
> # apt-cache showsrc amarok | grep Build-Depends | sed -e 's/[(]
> [^)]\+[)]//g' -e 's/,//g' | awk -F: '{print $2}' | xargs apt-get install
>
> to see what's wrong.

Thank you for the info. It indeed was the mixture of packages.

Ritesh
-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."


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

Bug#462078: ITP: libtie-toobject-perl -- Tie to an existing object

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>


* Package name: libtie-toobject-perl
  Version : 0.03
  Upstream Author : Yuval Kogman <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Tie-ToObject/
* License : Perl (Artistic/GPL)
  Programming Lang: Perl
  Description : Tie to an existing object

 While perldoc/tie allows tying to an arbitrary object, the class in question
 must support this in it's implementation of TIEHASH, TIEARRAY or
 whatever.

 Tie::ToObject class provides a very tie constructor that simply returns the 
 object it was given as it's first argument. This way side effects of calling 
 $object->TIEHASH are avoided.

 This is used in Data::Visitor in order to tie a variable to an already
 existing object. This is also useful for cloning, when you want to clone the
 internal state object instead of going through the tie interface for that
 variable.


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

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to pl_PL.UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#462081: ITP: libparanamer-java -- java library to access method parameter names at runtime

[Varun Hiremath]

Package: wnpp
Owner: Varun Hiremath <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: libparanamer-java
  Version : 1.1
  Upstream Author : Paul Hammant
* URL or Web page : http://paranamer.codehaus.org/
* License : BSD
  Description : java library to access method parameter names at runtime

  Paranamer is a library that allows the parameter names of methods
  and constructors to be accessed at runtime. It works with JDK 1.4
  and later.



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

Bug#462107: ITP: python-symeig -- Symmetrical eigenvalue routines for NumPy

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko <[EMAIL PROTECTED]>


* Package name: python-symeig
  Version : 1.2
  Upstream Author : Pietro Berkes and Tiziano Zito
* URL : http://mdp-toolkit.sourceforge.net/symeig.html
* License : LGPL
  Programming Lang: Python
  Description : Symmetrical eigenvalue routines for NumPy

Python wrapper for the LAPACK functions to solve the standard and
generalized eigenvalue problems for symmetric (hermitian) positive
definite matrices. Those specialized algorithms give an important
speed-up with respect to the generic LAPACK eigenvalue problem solver
used by NumPy (linalg.eig and linalg.eigh).

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-amd64
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]

Re: Correct spelling/capitalisation of project names

[Russ Allbery]

Christian Perrier <[EMAIL PROTECTED]> writes:

> Would "Emacs" and "XEmacs" qualify for this check?
>
> Even though "emacs" may make sense when talking about the command (while I
> really wonder why one would mention a command in a package
> description), checking for incorrect "EMacs" spelling would be good.
>
> Please note that I found no proposal to check for "vi" correct spelling.

I've added corrections for EMacs, Xemacs, and XEMacs.  I'm a bit more
hesitant for emacs and xemacs, for similar reasons to why I haven't added
a correction for perl -- the lowercase terms have a history of being used
within the communities around those applications, I think.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#462142: ITP: libcss-squish-perl -- Compact many CSS files into one big file

[Niko Tyni]

Package: wnpp
Severity: wishlist
Owner: Niko Tyni <[EMAIL PROTECTED]>

* Package name: libcss-squish-perl
  Version : 0.07
  Upstream Author : Thomas Sibley <[EMAIL PROTECTED]>, Ruslan Zakirov <[EMAIL 
PROTECTED]>
* URL : http://search.cpan.org/dist/CSS-Squish/
* License : GPL-1+ | Artistic
  Programming Lang: Perl
  Description : Compact many CSS files into one big file

CSS::Squish is a Perl module that takes a list of CSS files and
concatenates them, making sure to honor any valid @import statements
included in the files.


This module is needed by the latest version of request-tracker3.6.

The package will be maintained under the Debian Perl Group
<[EMAIL PROTECTED]> umbrella.



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

Re: [rfc] mass-mod old ita/itp bugs back to rfa/rfp?

[Sebastian Pipping]

Andreas Tille wrote:

A further enhancement would be to not list merged bugs because both bugs
are mentioned on your page.


Right. I'm not sure about the best way yet. I think MySQL can
help me with that but not sure yet how exactly.




Sebastian


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

Bug#462152: O: smake -- Schily make.

[Joerg Jaspert]

Package: wnpp
Severity: normal

Hi

i want to get rid of this package. Want it? Take it, but careful, its
Upstream is JS. If noone in a week or so - removing is also nice.


Package: smake
Priority: optional
Section: devel
Installed-Size: 268
Maintainer: Joerg Jaspert <[EMAIL PROTECTED]>
Architecture: amd64
Version: 1.2a23-1
Depends: libc6 (>= 2.3.5-1)
Filename: pool/main/s/smake/smake_1.2a23-1_amd64.deb
Size: 78314
MD5sum: c4a1775e612d77b03d00719a569820b2
SHA1: 27c5abaed653e1a2c7f5895b3ef1d60c7ff734ec
SHA256: 2a6add53bbc69776ff8e32bbb4853a34769c1cf6db2cc03b8a8f72225dc7a98a
Description: Schily make. Portable, extensible make
 A portable make program optimized to be used with 'makefiles'.
 smake includes special automake features that allow to do
 easy portable compilation.


-- 
bye Joerg
You're in good shape for being a Debian, with a SAP background
... anything has to look good from there...



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

Re: dpkg symbol handling: looking for advice on #MISSING symbols

[Jiri Palecek]

Stefano Zacchiroli wrote:

> Hi all,
>   I'm new to the dpkg symbol handling stuff and I'm trying to add
> symbols support to the gtkmathview source package. According to
>
http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libgtkmathview0c2a_i386
> there are already symbols which have been missing between stable version
> (0.7.7) and the latest two versions in unstable (0.8.0-{1,2}), list
> attached.  However, upstream author claims that no symbols have been
> removed in between.
> 
> AFAIU in the list there are a lot of template generated code symbols and
> other stuff coming from the C++ standard library. Can it be that
> something changed in the C++ name handling code or something such? Or

AFAIK, no.

> something which should have been marked as private has been leaked
> erroneously in the public ABI?

I just don't know what you mean by "mark as private".

I'm not an expert on linking and only had a brief look at it but, AFAICT
there are three kinds of functions missing:

1) inline functions that somehow weren't generated, but are still in the
source -- -fkeep-inline-functions should take care of that (or,
maybe, -fvisibility-inlines-hidden)

2) templated code like std::find -- this should be probably with hidden
visibility, unless it is an explicit instantiation. Since the code already
marks some classes as "exported", you could probably do -fvisibility=hidden
without too much effort

3) functions that changed their signatures -- there upstream _did_ change
the API, so if you want applications built with the old version run with
the new one, you have to reintroduce the overloads with the old signatures

Regards
Jiri Palecek




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

Re: Future Debian package candidate web pages: present and future

[Raphael Geissert]

Lucas Nussbaum wrote:
> On 17/01/08 at 23:48 +0100, David Bremner wrote:
>> > "Sebastian" == Sebastian Pipping <[EMAIL PROTECTED]> writes:
>> Sebastian>> David Bremner wrote:
>> 
>> >> I would really like some (approximate) popcon data myself,
>> >> especially for orphaned packages.
>> 
>> Sebastian> would be cool, yes. i don't have any clue to do this
>> Sebastian> yet. if you do please share your thoughts with me to
>> Sebastian> speed the thing up. deal? :-)
>> 
>> As far as I understand it (and maybe somebody more informed can
>> correct me), there is currently no fancy interface (SOAP) to the data
>> on popcon.debian.org  On the other hand, it does not change that
>> quickly, so grabbing a copy once a week should be reasonable.
>> 
>> http://qa.debian.org/popcon.php?package=whatever
>> 
>> obviously has access to the data, so maybe someone on the qa team can
>> comment.
> 
> You could simply download it from http://popcon.debian.org/ and parse
> it...

Or read it from http://qa.debian.org/data/popcon/ which AFAIR is updated
daily.


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

Re: Future Debian package candidate web pages: present and future

[Sebastian Pipping]

Raphael Geissert wrote:

You could simply download it from http://popcon.debian.org/ and parse
it...


Or read it from http://qa.debian.org/data/popcon/ which AFAIR is updated
daily.


I see two problems with the latter: I'd have to either choose
between the one column file (too little data) or the 64 MB
database (too much size). currently i am reading from here:

   http://popcon.debian.org/source/by_inst.gz

that's both small and detailed enough. i'm still working
on the integration though. if only i were better at SQL :-)




sebastian


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

Bug#462181: ITP: pecomato -- Picture-embedded contents manipulation tool

[Ricardo Mones]

Package: wnpp
Severity: wishlist
Owner: Ricardo Mones <[EMAIL PROTECTED]>


* Package name: pecomato
  Version : 0.0.15
  Upstream Author : Tristan Chabredier <[EMAIL PROTECTED]>
* URL : http://www.mollux.org/projects/pecomato/
* License : GPL2/GPL3
  Programming Lang: C
  Description : Picture-embedded contents manipulation tool

 PECoMaTo is a metadata processor designed to display any kind 
 of information embedded in picture files, as well as checking, 
 filtering, extracting, removing, adding and fixing such 
 information.
 .
 It supports the following file formats: JPEG/JFIF, Adobe PSD,
 FFO and raw IPTC. And it knows about the following metadata 
 formats: JFIF, IPTC, Exif, Adobe and Fotostation. 
 .
 One of its main goals is to check the validity of parsed 
 metadata as well as optionally check the strict compliance 
 to official standards. On another hand, it aims to provide 
 ways of fixing broken or not compliant chunks as well as 
 providing general basic functions to manipulate the metadata.

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

Kernel: Linux 2.6.23-1-amd64 (SMP w/1 CPU core)
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash



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

Re: Future Debian package candidate web pages: present and future

[Sebastian Pipping]

David Bremner wrote:

[..] I would really like some (approximate)
popcon data myself, especially for orphaned packages. [..]


added! it was a left join that i needed here. yeha! :-)

this should list orphaned packages in decending order
of minimum number of people using them:
http://debian.binera.de/wnpp/?type%5B%5D=O&sort=users;desc



sebastian


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

Re: loosing dependencies: Depends: on logrotate

[Sven Mueller]

Ivan Shmakov schrieb:
>   Since I've already started this thread, I'm going to ask for
>   opinions on the one more issue with the current (Etch, at least)
>   dependencies in Debian to bother me.
> 
>   Is `logrotate' really necessary for those 46 packages or so in
>   Etch to include it in their `Depends:'?
> 
>   Debian Policy reads:
> 
> --cut: www.debian.org/doc/debian-policy/ch-relationships.html--
> The Depends field should be used if the depended-on package is
> required for the depending package to provide a significant amount
> of functionality.
> 
> The Depends field should also be used if the postinst, prerm or
> postrm scripts require the package to be present in order to
> run.  Note, however, that the postrm cannot rely on any
> non-essential packages to be present during the purge phase.
> --cut: www.debian.org/doc/debian-policy/ch-relationships.html--
> 
>   My opinion is that since `logrotate' is not required neither for
>   the maintainer scripts in order to run, nor ``for the depending
>   package to provide a significant amount of functionality'', this
>   dependency should be either relaxed (to `Recommends:' or
>   `Suggests:') or discarded completely.

Exactly. If any of the old, rather inflexible syslog implementations
depended on logrotate, I would say that would be perfectly fine. But for
applications (even if they write their logs themselves like apache or
samba usually do), I would only expect a simple Recommends.
On my servers, I'm forced to have logrotate installed due to
applications like samba, even though I immediately disable logrotate
after installation and use my own rotation scripts (for those
applications not using syslog - syslog-ng in this case) instead.

I do see the argument about a maintainer best making as sure as possible
that a user doesn't run into problems unless he overrode the packages
defaults. But in this sense, a Recommends is a package default, and the
user should be expected to know what he does if he doesn't install
Recommends.

Given the example of Samba, logrotate isn't _needed_ to provide any
amount of functionality of the software packaged and more specifically
not needed to provide a _significant_ amount of functionality. Following
this argument, one could even suggest that listing logrotate as a
Depends is a policy violation (and as such release critical). The
exception made for maintainer scripts doesn't fit here either, since the
maintainer scripts don't use logrotate.

I didn't check, but I would guess that the same is true for many of the
other packages in Sid that depend on logrotate.

So IMHO, most of those packages really should only Suggest logrotate.

cu,
Sven



signature.asc
Description: OpenPGP digital signature

Re: loosing dependencies: Depends: on logrotate

[Don Armstrong]

On Wed, 23 Jan 2008, Sven Mueller wrote:
> Exactly. If any of the old, rather inflexible syslog implementations
> depended on logrotate, I would say that would be perfectly fine. But
> for applications (even if they write their logs themselves like
> apache or samba usually do), I would only expect a simple
> Recommends. On my servers, I'm forced to have logrotate installed
> due to applications like samba, even though I immediately disable
> logrotate after installation and use my own rotation scripts (for
> those applications not using syslog - syslog-ng in this case)
> instead.

You need to have some kind of log rotation in place, so a depends[0]
is perfectly appropriate, since the only type of log rotation that we
actually distribute is logrotate.[1] (I mean, without *some* kind of
log rotation, you're going to run out of disk space eventually, which
seems to me to be a pretty important bit of functionality.) Since
samba even distributes an appropriate logrotate config file, it
obviously depends on it.

Finally, it's not like you can't indicate that you're dealing with
logrotation by yourself by using an equivs package to work around the
dependency.


Don Armstrong

0: And actually, it's not clear to me why syslog-ng doens't depend on
logrotate.
1: TTBOMK, of course; if there are others, then there possibly should
be a metapackage for them.
-- 
The state must declare the child to be the most precious treasure of
the people. As long as the government is perceived as working for the
benefit of the children, the people will happily endure almost any
curtailment of liberty and almost any deprivation.
 -- Adolf Hitler _Mein Kampf_ p403

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Correct spelling/capitalisation of project names

[Christian Perrier]

openldap -> OpenLDAP
Openldap -> OpenLDAP
OpenLdap -> OpenLDAP

I haven't checked if these mistakes are often used or not,
though. Just popped in my mind while working on OpenLDAP debconf
templates..(which have no error of course).

Also, what about checking debconf templates? I think that the
probability of false positives there is quite low as long as you take
care to check "Description" only ("_Description", indeed).

The check could either be done on the source debconf templates (listed
in debian/po/POTFILES.in) or on the DEBIAN/templates file in binary
packages. The latter adds the possibility for checking proper
capitalization in translated templates (I see no real reason for
translations to change capitalization when mentioning project names
that should remain untranslatable).






signature.asc
Description: Digital signature