Re: ur link will be aproved

[Aryan Singh]

बातें करके रुला ना दीजिएगा...
यू चुप रहके सज़ा ना दीजिएगा...

ना दे सके ख़ुशी, तो ग़म ही सही...
पर दोस्त बना के यूही भुला ना दीजिएगा...

खुदा ने दोस्त को दोस्त से मिलाया...
दोस्तो के लिए दोस्ती का रिस्ता बनाया...

पर कहते है दोस्ती रहेगी उसकी क़ायम...
जिसने दोस्ती को दिल से निभाया...

अब और मंज़िल पाने की हसरत नही...
किसी की याद मे मर जाने की फ़ितरत नही...

आप जैसे दोस्त जबसे मिले...
किसी और को दोस्त बनाने की ज़रूरत नही ***!



Cheers,
Aryan

Re: Bug#463862: ITP: ipafont -- Japanese high quality TrueType font

[Christian Perrier]

Quoting Hideki Yamane ([EMAIL PROTECTED]):
> On Sun, 03 Feb 2008 15:43:27 -0600
> William Pitcock <[EMAIL PROTECTED]> wrote:
> > This should be ttf-ipafont.
> 
>  Yes, binary package name is ttf-ipa, but source package name
>  is ipafont.


Is there a reason to not use "ttf-ipafont" as source package
name? Nothing specifically requires this but that makes spotting TTF
fonts easier.



signature.asc
Description: Digital signature

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[Anthony Towns]

On Sun, Feb 03, 2008 at 04:30:09PM -0600, William Pitcock wrote:
> > Currently, the packages that are asking for wx2.8 are almost all available
> > and releasable in earlier versions, built against wx2.6.  Uploading wx2.8 to
> > unstable implies that it's suitable for apps to build against, which by all
> > accounts it is not.
> Maybe an upload to experimental would be appropriate then?

Usually.

Cheers,
aj


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

Re: Standardisation of the name of the patching targets included in debian/rules.

[Simon Horman]

On Sun, Feb 03, 2008 at 08:14:35PM +0100, Stefano Zacchiroli wrote:
> On Sun, Feb 03, 2008 at 11:10:41AM +0100, Martin Quinson wrote:
> > I find personnaly patch/unpatch more easy to understand, but YMMV...
> 
> I think (hope) that no one will be able to find a reason why the two
> target should *not* be called "patch" / "unpatch". They are IMO the only
> 2 that people will be able to guess out of the blue.
> 
> So please go for patch/unpatch.

Fine by me.

Though if you dug a bit deeper I suspect you would find rather a
lot of packages that supply patch/unpatch targets under various names.

Perhaps a policy is in order? That way lintian and friends would
alert packagers to the problem.



-- 
Horms


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

Re: Bug#463873: ITP: pondus -- personal weight manager for GTK+2

[Hamish Moffatt]

On Sun, Feb 03, 2008 at 11:01:36PM +0100, Eike Nicklas wrote:
>   Description : personal weight manager for GTK+2
> 
>  Pondus keeps track of your body weight. It aims to be simple to use,
>  lightweight and fast.

Is that a bad pun?


I am to be lightweight too. Perhaps pondus will help.


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


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

Re: Standardisation of the name of the patching targets included in debian/rules.

[Petter Reinholdtsen]

[Simon Horman]
>> So please go for patch/unpatch.
>
> Fine by me.

I would very much like the targets to be short and to the point, as I
use the patch and unpatch quite a lot in my workflow.  Because of
this, I also would like patch/unpatch over the observed alternative.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: NMU campaign for control|changelog encoding issues

[Javier Fernandez-Sanguino]

2008/2/4, Christian Perrier <[EMAIL PROTECTED]>:
> I started yesterday to NMU such packages, beginning with those that
> have wrongly encoded debian/control files (and most often *also* a
> wrongly encoded debian/changelog and *even* debian/copyright).

I'll fix and upload harden-doc and tiger myself. Please don't NMU
these (unless you see I don't follow up with fixes in a few weeks or
so)

Regards

Javier


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

Re: changing the default syslog daemon for lenny?

[Tollef Fog Heen]

* William Pitcock 

| I agree with this. Additionally, Balasz Schielder (Balabit) makes people
| who contribute to syslog-ng sign a contributory license agreement [1],
| so that they can be included in syslog-ng premium, which is in my view
| against the whole purpose of open source. If you disagree with signing
| the CLA, your patch is rejected. As such, I feel that syslog-ng is not a
| good choice for the default syslogd in Debian.

FWIW, if you want your patch to end up in any Apache project, you have
to sign their contributor licence agreement.  Similarly, for GNU
software, you have to assign copyright to FSF.

The syslog-ng author putting the changes into a closed-source version
(if I understand the paragraph quoted correctly), which is fine as
long as the licence allows it.  You might not think it's in the spirit
of free software, but it's certainly something one of the arguments
some people are using to get people to use the BSD licence in favour
of the GPL.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[Richard Hartmann]

Hi again,


after some discussion on #debian-devel yesterday, two options were more
or less agreed upon with Ron Lee:

  1) People who have an interest in 2.8 contact Ron to work together.

  2) People are free to upload 2.8 as a separate package without him
 minding the fact that his namespace is impacted, as he does not
 currently plan to package 2.8 anyway, preferring to wait for 3.0.


If the package proves to be as unstable as Ron claims it to be, it could
easily remain in experimental, offering the packagers who depend on 2.8
a chance to get their packages into a central place where users who are
aware of the issues can get it from. If it proves to be
stable enough for daily use, but not bug free, it will make it into
unstable, but the bugs will keep it out of testing, anyway. Personally,
I am using Bastian Kleineidam's packages without any problems.


Best regards,
Richard Hartmann


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

Re: dpatch, "diff -u" and "very big projects"

[Ondrej Certik]

On Feb 3, 2008 5:38 AM, Charles Plessy <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> http://wiki.debian.org/debian/patches is world-writeable, and attempts
> to summarize what was said in this thread and in the Policy discussions
> about 'README.source'. Do not hesitate to edit it !

Thanks for summarizing it!

Ondrej


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

Re: Standardisation of the name of the patching targets included in debian/rules.

[Colin Watson]

On Mon, Feb 04, 2008 at 05:28:14PM +0900, Simon Horman wrote:
> On Sun, Feb 03, 2008 at 08:14:35PM +0100, Stefano Zacchiroli wrote:
> > On Sun, Feb 03, 2008 at 11:10:41AM +0100, Martin Quinson wrote:
> > > I find personnaly patch/unpatch more easy to understand, but YMMV...
> > 
> > I think (hope) that no one will be able to find a reason why the two
> > target should *not* be called "patch" / "unpatch". They are IMO the only
> > 2 that people will be able to guess out of the blue.
> > 
> > So please go for patch/unpatch.
> 
> Fine by me.
> 
> Though if you dug a bit deeper I suspect you would find rather a
> lot of packages that supply patch/unpatch targets under various names.
> 
> Perhaps a policy is in order? That way lintian and friends would
> alert packagers to the problem.

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

(The discussion is long, but has recent activity.)

-- 
Colin Watson   [EMAIL PROTECTED]


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

Bug#463973: ITP: deejayd -- A media player daemon

[Alexandre Rossi]

Package: wnpp
Severity: wishlist
Owner: Alexandre Rossi <[EMAIL PROTECTED]>


* Package name: deejayd
  Version : 0.6.2
  Upstream Author : Mickaël Royer <[EMAIL PROTECTED]>
* URL : http://mroy31.dyndns.org/~roy/projects/deejayd/
* License : GPL
  Programming Lang: Python
  Description : A media player daemon

Deejayd is a multi purpose media player that can be completely controlled
through the network using XML messages.
It suppports playlists, searching, many media tags. It can playback many
music and video formats using either its xine (recommended) or its gstreamer
backend.

Preliminary packaging may be browsed in the upstream VCS viewer[0]. Built
packages work well, are lintian and linda clean, and build in a clean pbuilder
chroot.

I plan to search for a sponsor once we sort some internal bug and some
packaging issues (remove debian/* from upstream tarball[1] as DDs mostly seem
to prefer that).

Reporting any issue (on the packaging or on the sofware) is very welcome,
especially because this is my first debian package.

[0] http://mroy31.dyndns.org/~roy/projects/deejayd/browser
[1] http://mroy31.dyndns.org/~roy/archives/deejayd/deejayd-0.6.2.tar.gz

-- 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-6-vserver-amd64
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)

Re: How to cope with patches sanely

[John Goerzen]

On Sun February 3 2008 10:47:59 am Raphael Hertzog wrote:
> On Sat, 02 Feb 2008, Kumar Appaiah wrote:

> I was explaining how I would handle patches on top of upstream code. And
> where you have to update the patches when the upstream code changes.
> Rebase is exactly the process of "updating patches" while merge is really
> "keep the old patch and add fixups patch to reconcile after conflicts".

From what I remember of looking at rebase when I was evaluating git, isn't a 
side effect of it that it causes inconvenience for everyone that tracks your 
tree?  That is, if you are going to use rebase on a tree, it is generally a 
private tree used on only one of your own machines, rather than something 
that others pull from as well?

I have yet to see a convenient way to manage this, with any VCS whatsoever, 
that:

1. Lets you easily check out the state of the patched tree as of any given 
point in time

2. Lets you easily maintain a patchset where the patches on any given version 
are clearly separated into logical patches that can easily be sent to 
upstream

3. Facilitates teamwork with others using your repo

The closest that I've seen yet is Mercurial's mq extension, which is 
quilt-like, in the mode where both the main repo and the mq area are 
versioned.  This fails #1 because you have to get the main repo and the mq 
area to the same point manually, but succeeds on the others.

I also am meaning to toy around with Mercurial's transplant extension, which 
can be similar to git's rebase (I gather), but with some other 
tree-manipulating features.  But that fails the "easily" part because it's 
fairly esoteric VCS stuff.

Frankly I have been able to keep my deltas to upstream small enough that just 
using a basic Mercurial repo for this has been fine.  Although I maintain a 
fairly large package (Bacula), it is still nowhere near the size of KDE and 
X, and I also have the benefit of a very good working relationship with 
upstream.

-- John

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[Ron]

> Richard Hartmann writes:
> after some discussion on #debian-devel yesterday, two options were more
> or less agreed upon with Ron Lee:

Richard, please don't profess to speak for me -- especially not couched
in terms such as "more or less".  There were several things that people
tried to explain to you in that discussion that you 'more or less'
refused to accept, so please don't muddy the waters further by spreading
more misunderstanding.

>  1) People who have an interest in 2.8 contact Ron to work together.

As we discussed, as I've said previously, and as Myon already announced
once again, lets just start with this step shall we.  We can let the
people actually doing the work make judgements on where it will go from
there -- once some work actually gets done and is suitably reviewed.

I don't think many people were in agreement with your proposal that this
should be some sort of open-slather free for all.  It is going to take
quite an investment of time and effort for anyone who wants to attempt
this to get (and more importantly, keep) it in a state where it might
become part of the distro.

But anyone who thinks they are up for that, is indeed most welcome to
get in touch with myself and the others who've shown an interest to
date, to co-ordinate what they would like to do and how best to do it.
I don't think having some random number of people acting in isolation
will be sufficient to turn this into something usable.  If they exist,
they need to get together and all help each other.

Y'all know where to find us if you feel the itch.

Cheers,
Ron


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

Re: Automatic mirror selection

[Guillem Jover]

On Fri, 2008-02-01 at 21:09:24 +0100, Leo costela Antunes wrote:
> Adam Borowski wrote:
> > Uhm, and how exactly do you get the arch?  At DNS time you don't have
> > anything but the requester's or his ISP's IP.
> 
> This would have to be placed inside sources.list at some point, then I
> figure the automatic or manual process responsible should stick
> "dpkg-architecture -qDEB_BUILD_ARCH" somewhere in there, so you just
> have to query ".geomirror.d.net", for instance, to get the best
> mirror for your country which contains your arch.

You might want you use «dpkg --print-architecture» instead, so you
avoid a dependency on dpkg-dev.

regards,
guillem


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

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[Dirk Eddelbuettel]

Steve Langasek  debian.org> writes:
> On Sun, Feb 03, 2008 at 08:06:22PM +0100, Andreas Tille wrote:
> > Well, if we advise users to compile their stuff on their own
> > something is broken.  If we can not provide the latest upstream
> > version of a certain end user application because we are missing
> > some underlying libraries (for whatever reason) we IMHO failed
> > in supporting our users.

Fully agreed.

> Currently, the packages that are asking for wx2.8 are almost all available
> and releasable in earlier versions, built against wx2.6.  Uploading wx2.8 to
> unstable implies that it's suitable for apps to build against, which by all
> accounts it is not.

Wearing a Debian 'user' as well as 'developer' hat, I was stopped in the tracks
a few days ago when I tried to look at some C/c++ IDE (code::blocks) which 
would 
not configure on my testing box due to a lack of wxWidgets 2.8.

Not nice at all.  I can typically rely on Debian for having recent and common
software. In this case, Ubuntu won.  

Dirk





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

Re: Bug#463973: ITP: deejayd -- A media player daemon

[Christian Perrier]

Quoting Alexandre Rossi ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> Owner: Alexandre Rossi <[EMAIL PROTECTED]>
> 
> 
> * Package name: deejayd
>   Version : 0.6.2
>   Upstream Author : Mickaël Royer <[EMAIL PROTECTED]>
> * URL : http://mroy31.dyndns.org/~roy/projects/deejayd/
> * License : GPL
>   Programming Lang: Python
>   Description : A media player daemon

I suggest "media player daemon" or "media playing daemon"...but anyway
drop the leading article (DevRef 6.2.2)




signature.asc
Description: Digital signature

Re: How to cope with patches sanely

[Raphael Hertzog]

On Mon, 04 Feb 2008, John Goerzen wrote:
> On Sun February 3 2008 10:47:59 am Raphael Hertzog wrote:
> > On Sat, 02 Feb 2008, Kumar Appaiah wrote:
> 
> > I was explaining how I would handle patches on top of upstream code. And
> > where you have to update the patches when the upstream code changes.
> > Rebase is exactly the process of "updating patches" while merge is really
> > "keep the old patch and add fixups patch to reconcile after conflicts".
> 
> From what I remember of looking at rebase when I was evaluating git, isn't a 
> side effect of it that it causes inconvenience for everyone that tracks your 
> tree?  That is, if you are going to use rebase on a tree, it is generally a 
> private tree used on only one of your own machines, rather than something 
> that others pull from as well?

Yes it is. One needs to make it clear that a given branch is going to be
rebased and can't be used for merging.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Introducing security hardening features for Lenny

[Riku Voipio]

On Sun, Feb 03, 2008 at 08:53:00PM +0100, Moritz Muehlenhoff wrote:
> Did you followup with upstream on the SSP problems we've seen
> on ARM?

Basicly their response was basicly "why would anyone want
5-10% bigger and slower binaries on arm". It was also discussed
the possibility of --disable-ssp we use on our current arm/armel
toolchain being broken. Once I have a bit more time I'll try
seeing what happens if you build gcc-4.3 with ssp enabled.

-- 
"rm -rf" only sounds scary if you don't have backups


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

Re: How to cope with patches sanely

[Guillem Jover]

On Thu, 2008-01-31 at 10:54:11 +0100, Pierre Habouzit wrote:
>   Of course, that would mean that the few debian/rules (hi Manoj) in
> Debian not being makefiles [...]

You were probably thinking about Josip (and now the VDR team):

  

regards,
guillem


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

Re: Introducing security hardening features for Lenny

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/08 05:45, Riku Voipio wrote:
> On Sun, Feb 03, 2008 at 08:53:00PM +0100, Moritz Muehlenhoff wrote:
>> Did you followup with upstream on the SSP problems we've seen
>> on ARM?
> 
> Basicly their response was basicly "why would anyone want
> 5-10% bigger and slower binaries on arm". It was also discussed

Just MNSHO:

Because ARM systems are almost always embedded, and don't get
updated very often, so from the start should be as hardened as
possible against attack.

And if that means a 10% slowdown, so be it.

> the possibility of --disable-ssp we use on our current arm/armel
> toolchain being broken. Once I have a bit more time I'll try
> seeing what happens if you build gcc-4.3 with ssp enabled.

- --
Ron Johnson, Jr.
Jefferson LA  USA

PETA - People Eating Tasty Animals
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHpwaBS9HxQb37XmcRAqReAKDB0EjCnQ7eOA9/D2Ni0A4OpXyAcACdHXoz
XUDrWQyvB8uFH4rwJEI27fY=
=Iwd3
-END PGP SIGNATURE-


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

Re: Bug#463724: ITP: python-twitter -- A python wrapper around the Twitter API

[Mauro Lizaur]

On Feb 3, 2008 3:53 AM, Christian Perrier <[EMAIL PROTECTED]> wrote:
> Quoting Mauro Lizaur ([EMAIL PROTECTED]):
> > Package: wnpp Owner: Mauro Lizaur <[EMAIL PROTECTED]> Severity: wishlist
> >
> > * Package name: python-twitter
> >   Version : 0.5
> >   Upstream Author : DeWitt Clinton <[EMAIL PROTECTED]>
> > * URL : http://code.google.com/p/python-twitter/
> > * License : Apache-2.0
> >   Programming Lang: Python
> >   Description : A python wrapper around the Twitter API
>
> "twitter API wrapper for Python"
>
> - avoids leading article
> - puts the most important info at the beginning
> - proper capitalization of Python
>
> Maybe capitalize "Twitter" in case that project or thing (I have no
> idea what this might be) needs it.
>

Thanks Christian,
i've already fixed this in the package that i'm building.

-- 
BEGIN GEEK CODE BLOCK
Version: 3.12
GCM/O d->dpu$ s-:- a-->a+++$ C+++
LU P+ L++ E W+++ N !o K w O !M !V
PS+ PE Y+ PGP t 5– X R tv++ b- DI D++ G+ e
h!>h-- r>r+++ y+
END GEEK CODE BLOCK

Re: Bug#463862: ITP: ipafont -- Japanese high quality TrueType font

[Hideki Yamane]

On Mon, 4 Feb 2008 07:16:04 +0100
Christian Perrier <[EMAIL PROTECTED]> wrote:
> > William Pitcock <[EMAIL PROTECTED]> wrote:
> > > This should be ttf-ipafont.
> > 
> >  Yes, binary package name is ttf-ipa, but source package name
> >  is ipafont.
> 
> 
> Is there a reason to not use "ttf-ipafont" as source package
> name? Nothing specifically requires this but that makes spotting TTF
> fonts easier.

 Just because upstream tarball is provided as ipafont-xx.tar.gz, 
 so I use it. I don't mind to change its name.


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

Re: Bug#463973: ITP: deejayd -- A media player daemon

[Christian Perrier]

Quoting Ron Johnson ([EMAIL PROTECTED]):

> >> I suggest "media player daemon" or "media playing daemon"...but anyway
> >> drop the leading article (DevRef 6.2.2)
> >>
> >>
> > 
> > "media player daemon" may be confusing with mpd. "daemon which plays
> > media in the background" may be better.
> 
> More importantly: what is the benefit of deejayd over any other
> media player?  *That* would be useful info for the Full Description.


Yes. Apparently what's special about this is that it can be controlled
over the network. Probably not the only one but noticeable enough to
be mentioned in a short description.



signature.asc
Description: Digital signature

Re: Bug#463973: ITP: deejayd -- A media player daemon

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/08 14:22, William Pitcock wrote:
> On Mon, 2008-02-04 at 18:08 +0100, Christian Perrier wrote:
>> Quoting Alexandre Rossi ([EMAIL PROTECTED]):
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Alexandre Rossi <[EMAIL PROTECTED]>
>>>
>>>
>>> * Package name: deejayd
>>>   Version : 0.6.2
>>>   Upstream Author : Mickaël Royer <[EMAIL PROTECTED]>
>>> * URL : http://mroy31.dyndns.org/~roy/projects/deejayd/
>>> * License : GPL
>>>   Programming Lang: Python
>>>   Description : A media player daemon
>> I suggest "media player daemon" or "media playing daemon"...but anyway
>> drop the leading article (DevRef 6.2.2)
>>
>>
> 
> "media player daemon" may be confusing with mpd. "daemon which plays
> media in the background" may be better.

More importantly: what is the benefit of deejayd over any other
media player?  *That* would be useful info for the Full Description.

- --
Ron Johnson, Jr.
Jefferson LA  USA

PETA - People Eating Tasty Animals
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHp4OUS9HxQb37XmcRAv8zAKCQ/3WxrBFAvVF1zExqh7cgFT5w6gCfdadV
2ACbdREHqSecmeG7MzIyR+I=
=UNoq
-END PGP SIGNATURE-


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

Re: How to cope with patches sanely

[Pierre Habouzit]

On Mon, Feb 04, 2008 at 08:02:42PM +, Guillem Jover wrote:
> On Thu, 2008-01-31 at 10:54:11 +0100, Pierre Habouzit wrote:
> >   Of course, that would mean that the few debian/rules (hi Manoj) in
> > Debian not being makefiles [...]
> 
> You were probably thinking about Josip (and now the VDR team):
> 
>   

  Damn, I was pretty sure Manoj still had some custom perl things, but I
stand corrected :)
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp8Ph3x3dalv.pgp
Description: PGP signature

Re: Proposal: Alternatives: field for debian/control

[Neil Williams]

On Mon, 2008-02-04 at 14:26 -0600, William Pitcock wrote:
> Hi,
> 
> There's a lot of packages in Debian which do the same basic thing, but
> slightly differently. Having an Alternatives: field would be nice for
> listing alternative packages which package maintainers may find useful
> to try if the user does not like how the package they are installing
> behaves.

Sounds more like a job for debtags and ept-cache to me. The judgement
about whether two packages are "similar" enough to be "alternatives" can
be subjective, as shown by the previous discussions on xmms and
audacity. Such "fuzzy" relationships are best done with tags, IMHO.

(Also, let's not add yet more lines to the Packages.gz file?)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: Bug#463973: ITP: deejayd -- A media player daemon

[William Pitcock]

On Mon, 2008-02-04 at 18:08 +0100, Christian Perrier wrote:
> Quoting Alexandre Rossi ([EMAIL PROTECTED]):
> > Package: wnpp
> > Severity: wishlist
> > Owner: Alexandre Rossi <[EMAIL PROTECTED]>
> > 
> > 
> > * Package name: deejayd
> >   Version : 0.6.2
> >   Upstream Author : Mickaël Royer <[EMAIL PROTECTED]>
> > * URL : http://mroy31.dyndns.org/~roy/projects/deejayd/
> > * License : GPL
> >   Programming Lang: Python
> >   Description : A media player daemon
> 
> I suggest "media player daemon" or "media playing daemon"...but anyway
> drop the leading article (DevRef 6.2.2)
> 
> 

"media player daemon" may be confusing with mpd. "daemon which plays
media in the background" may be better.

William


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

Re: How to cope with patches sanely

[Russ Allbery]

Pierre Habouzit <[EMAIL PROTECTED]> writes:
> On Mon, Feb 04, 2008 at 08:02:42PM +, Guillem Jover wrote:
>> On Thu, 2008-01-31 at 10:54:11 +0100, Pierre Habouzit wrote:

>>>   Of course, that would mean that the few debian/rules (hi Manoj) in
>>> Debian not being makefiles [...]

>> You were probably thinking about Josip (and now the VDR team):

>>   

>   Damn, I was pretty sure Manoj still had some custom perl things, but I
> stand corrected :)

The VDR stuff actually is makefiles, too; it's a shell script wrapper
around make that, so far as I could tell with a quick look, doesn't do
anything that one couldn't do with a regular make include.  But I may be
missing some subtlety.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Automatic mirror selection

[Leo "costela" Antunes]

Guillem Jover wrote:
> You might want you use «dpkg --print-architecture» instead, so you
> avoid a dependency on dpkg-dev.

Good point.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Proposal: Alternatives: field for debian/control

[William Pitcock]

Hi,

There's a lot of packages in Debian which do the same basic thing, but
slightly differently. Having an Alternatives: field would be nice for
listing alternative packages which package maintainers may find useful
to try if the user does not like how the package they are installing
behaves.

As for the interface, I think that this would be useful and intuitive:

# apt-get install ircd-irc2
..
The following NEW packages will be installed:
 ircd-irc2
The following packages are alternatives to the packages being installed:
 inspircd ircd-ircu ircd-hybrid ircd-ratbox

This would especially be useful for when people install a virtual
package, so that they can get an overview of what other options are
available.

William


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

New Subdivision at Mount Baldy, British Columbia

[BCResortHomes.com]

Mount Baldy releases new lots to the public
2008 has seen the introduction of the new Sugar Lump quad chair and the launch 
of the McKinney subdivision just a short "ski-in" away from the lift. Mount 
Baldy has been growing in skier numbers and real estate launches for several 
years now and is rapidly getting a reputation for high quality skiing in powder 
snow. So much so, that other regional ski area staff take days off at Baldy to 
experience true champagne powder.On February 1st we will commence accepting 
priority reservations for the public purchase of the first 24 lots in the 
McKinney subdivision. 

Generous sized single family lots, with a variety of views and exposures. Ski 
to and ultimately ski from this new subdivision adjacent to the main village 
core lifts. The lots in the subdivision allow a selection of great views, 
tranquility and ski-in, ski-out locations.

For the first time ever at Mount Baldy, lot purchasers will be given an 
exclusive opportunity to get cash rebate incentives for simply purchasing a lot 
and further for building within a set timeframe. 
Now is a great time to invest in this newly master planned resort in the south 
Okanagan. Mount Baldy's future is very bright as investment continues on the 
mountain and skier numbers increase daily. Ask us about the great CASH BACK 
incentive for the lots.

To register for more information, CLICK THIS LINK.Click here to download our 
latest newsletter.

This is not an offer for sale which can only be made by disclosure in the 
province of BC

We believe in responsible email marketing procedures. If you believe you have 
received this email in error, or if you wish to be removed from our email list, 
please respond to this email with the word REMOVE in the subject line.
Thank you

Intend to hijack rrdtool

[Bernd Zeimetz]

[CCing [EMAIL PROTECTED] as he is listed as Uploader]

Hi,

as rrdtool is a vital part of a lot of system monitoring solutions and
should not go into Lenny in its current unmaintained state, I intend to
hijack it.

Unfortunately the current rrdtool package
- is outdated. Currently we have 1.2.19 in testing, while 1.2.26 is out
now, which does not only include a lot of bugfixes (not only for bugs in
Debian's BTS) but also has a significantly improved performance.
[EMAIL PROTECTED] was pinged several times about updating the package, in
#431060 (4 times), on irc (#debian-devel/oftc, Dec 02 2007 03:45 CET)
and also by a mail from me to him one week ago, which was also forwarded
to the MIA team.

- has a high bugcount:
   All bugs 25
   RC bugs  2
   I&N bugs 14
   M&W bugs 8
   F&P bugs 1
(while the only F&P bug the mentioned #431060, which is tagged pending
for 33 days now, while being open for 220 days). Looking at the archived
bugs there were only a few bugs closed by the current maintainer, all
open bugs are several months old now.

- Still ignores the new Python policy completely.


If there are no objections I want to upload a new and heavily overworked
package in about two weeks as the very soft freeze for Lenny will be in
the early march, so there's at least some time left for intensive testing.


Best regards,

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Proposal: Alternatives: field for debian/control

[Julian Andres Klode]

William Pitcock wrote:
> Hi,
> 
> There's a lot of packages in Debian which do the same basic thing, but
> slightly differently. Having an Alternatives: field would be nice for
> listing alternative packages which package maintainers may find useful
> to try if the user does not like how the package they are installing
> behaves.
> 
> As for the interface, I think that this would be useful and intuitive:
> 
> # apt-get install ircd-irc2
> ..
> The following NEW packages will be installed:
>  ircd-irc2
> The following packages are alternatives to the packages being installed:
>  inspircd ircd-ircu ircd-hybrid ircd-ratbox
> 
> This would especially be useful for when people install a virtual
> package, so that they can get an overview of what other options are
> available.
I don't think that this a good idea. You can use aptitude show
virtual-package to see which packages provide the virtual package.
We also have Suggests:, which is (sometimes) used for listing alternative
packages.

> 
> William


-- 
Julian Andres Klode, Fellow of the Free Software Foundation Europe
 Ubuntu Member | Debian Packager | Developer

try Ubuntu: http://www.ubuntu.com/ | my site: http://jak-linux.org/
 mail: [EMAIL PROTECTED]  | IRC: juliank
languages: German  | English



signature.asc
Description: OpenPGP digital signature

Re: Bug#463973: ITP: deejayd -- A media player daemon

[Cyril Brulebois]

On 04/02/2008, Christian Perrier wrote:
> Yes. Apparently what's special about this is that it can be
> controlled over the network. Probably not the only one but
> noticeable enough to be mentioned in a short description.

mpd also supports that (tcp/6600).

Cheers,

-- 
Cyril Brulebois


pgpARDt4RZ7TJ.pgp
Description: PGP signature

Re: Proposition: 'NMU' upload of wxwidgets 2.8

[Miles Bader]

Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> Wearing a Debian 'user' as well as 'developer' hat, I was stopped in the 
> tracks
> a few days ago when I tried to look at some C/c++ IDE (code::blocks) which 
> would 
> not configure on my testing box due to a lack of wxWidgets 2.8.
>
> Not nice at all.  I can typically rely on Debian for having recent and common
> software. In this case, Ubuntu won.  

So are the purported problems with wxw 2.8 bad or not?

-Miles

-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.


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

Re: How to cope with patches sanely

[Manoj Srivastava]

On Mon, 04 Feb 2008 22:24:09 +0100, Pierre Habouzit <[EMAIL PROTECTED]> said: 

> On Mon, Feb 04, 2008 at 08:02:42PM +, Guillem Jover wrote:
>> On Thu, 2008-01-31 at 10:54:11 +0100, Pierre Habouzit wrote:
>> >   Of course, that would mean that the few debian/rules (hi Manoj)
>> > in Debian not being makefiles [...]

>> You were probably thinking about Josip (and now the VDR team):
>> 

>   Damn, I was pretty sure Manoj still had some custom perl things, but
> I stand corrected :)

What do you mean, still? I have never used anything but make in
 my rules files; indeed, I was the one who has (over the objections of a
 few people) maintained that the policy of requiring Make files make
 sense.

I do have Perl maintainer scripts, though.

manoj
-- 
A clever prophet makes sure of the event first.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sat, 26 Jan 2008 00:05:32 +, Darren Salt
<[EMAIL PROTECTED]> said:  

> Whatever DSCM is used, it needs history truncation.

Umm. Why would any distributed version control system always
 need history truncation?  I am not even sure that arch has such a
 thing; and I have never felt the need for such a beast.

A distributed VCS that bundles in the whole archive in every
 checkout might well need that, but not all distributed VCS systems do
 that.

manoj
-- 
The wise and intelligent are coming belatedly to realize that alcohol,
and not the dog, is man's best friend.  Rover is taking a beating -- and
he should. -- W.C. Fields
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug#463973: ITP: deejayd -- A media player daemon

[Alexandre Rossi]

> > Yes. Apparently what's special about this is that it can be
> > controlled over the network. Probably not the only one but
> > noticeable enough to be mentioned in a short description.
>
> mpd also supports that (tcp/6600).

Yep this project is very similar to mpd. As far as I know, it improves
over mpd with the following features :
- play queue
- video support (this is also an advantage over XMMS2 but I do not
know this project well enough to do a full comparison)
- xine or gstreamer backend (i.e. more supported media formats, well
tested media backends)
- more easily extensible protocol because of XML and easier to extend
because of Python
- asynchronous notifications other the network (you can subscribe to
song changes, etc, XMMS2 also has this)
- webradios dedicated mode
- integrated web interface

It has the following drawbacks compared to mpd :
- uses more memory and perhaps more CPU time (because written in
Python vs optimized C) but it keeps reasonable, you'll see if you give
it a try.
- no ReplayGain support (this is a planned feature).
- younger project thus less stable, less tested although the codebase
is not very large (we use everything we can reuse) and we've got quite
a big test suite.
- no Zeroconf support.
- only 3 clients (cmdline, web, maemo platform) and GUIs still have rough edges.

This is a summary of what I know. I think all those projects are
complementary. deejayd does not have (yet?) unique features, but it is
a unique combination of features.

Also of interest, there is a page that explains why we started the project.
http://mroy31.dyndns.org/~roy/projects/deejayd/wiki/Why/

Should all this fit in the package description?

Thanks,

Alex


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

Re: How to cope with patches sanely

[Manoj Srivastava]

On Sat, 26 Jan 2008 11:34:27 -0500, David Nusinow
<[EMAIL PROTECTED]> said:  

> What bothers me about Joey's blog entry, and other similar proposals,
> is that it ignores a major reason for having external patch systems in
> the first place. Many of us have to carry long-lived patches to very
> complicated software. I'm personally thinking of the X server, but
> there are bound to be other examples. Additionally, we often have to
> carry several of these throughout the lifetime of the package. We also
> have to carry patches that aren't yet suitable for upstream, but may
> eventually become so. Finally, we have to carry patches backported
> from upstream HEAD.

I have beeing doing this for some of my packages using arch; and
 while none of my packages are as large as X, it has worked out  quite
 well for me.

> The idea proposed by many people, to keep the patches merged in your
> debian-specific branch, only really improves lives in the last case,
> when those patches are going to be merged in for the future anyhow. In
> any case where you have a patch that isn't going to go upstream for a
> long while, if ever, keeping these patches merged becomes painful.

This has not been my experience with feature branches +
 integration branch.

> If the patches are large, then you'll forget most all of the details
> which makes merging painful. Additionally, it becomes quite difficult
> to see a large patch that touches many files in the whole. A great
> deal of archaelology becomes necessary to cope with that. If the patch
> becomes suitable to go upstream after some time, it also becomes hard
> to extract that patch to be sent later.

> An alternate idea I keep seeing is feature branches. I have absolutely
> no idea why these are considered preferable to most people. In the
> case of the X server we regularly carry around 30 patches on our
> stack. If we were to put each of these on its own unique feature
> branch, merging them becomes an exercise in pain. Sure, we could
> implement our own custom scripts and have very strict naming policies,
> but then you've re-invented the wheel and congratulations, you have
> yet another custom piece of crap software that you have to maintain on
> top of the already complicated one you actually care
> about. Additionally, you have a lot more branches getting in the way
> when you're trying to figure out which one you're looking for.

In my experience, once I have created  the integration branch,
 most upstream versions require little to none re-merging; I just apply
 the delta to each of the feature branches, _and_ the integration
 branch. Very rarely do I have to fix up a feature branch, and then
 apply a second delta with that fix up to the integration branch; but it
 has not been, for me, painful at all, nor do I have to jump through
 hoops every single time to accommodate new upstream.

> If we can't figure out a good and clean way to keep a large stack of
> long-lived patches in the vcs then I firmly believe we should
> standardize on quilt.

I think I have indeed solved the issue of long standing feature
 sets using feature branches, integration branches, and sloppy branches
 while upgrading, and would not want to be forced to regress to a patch
 system. 

manoj
-- 
Usage: fortune -P [] -a [xsz] [Q: [file]] [rKe9] -v6[+] dataspec
... inputdir
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug#463973: ITP: deejayd -- A media player daemon

[Hamish Moffatt]

On Tue, Feb 05, 2008 at 07:34:06AM +0100, Alexandre Rossi wrote:
> > > Yes. Apparently what's special about this is that it can be
> > > controlled over the network. Probably not the only one but
> > > noticeable enough to be mentioned in a short description.
> >
> > mpd also supports that (tcp/6600).
> 
> Yep this project is very similar to mpd. As far as I know, it improves
> over mpd with the following features :
> - play queue

mpd has a play queue.

> - video support (this is also an advantage over XMMS2 but I do not
> know this project well enough to do a full comparison)

Isn't that a client/front-end issue?

> - xine or gstreamer backend (i.e. more supported media formats, well
> tested media backends)

OK.

> - more easily extensible protocol because of XML and easier to extend
> because of Python

Wow, XML. Shiny! It must be better then(?).

> It has the following drawbacks compared to mpd :
> - uses more memory and perhaps more CPU time (because written in
> Python vs optimized C) but it keeps reasonable, you'll see if you give
> it a try.

DSP in pure Python? Hopefully not.


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


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