use of "Uploaders:" field for team maintained packages

2007-10-20 Thread Bart Martens
Hi Debian Packagers,

I'm surprised that /usr/share/doc/gnome-pkg-tools/README.Debian.gz
contradicts with the good practices described in developers reference.

See /usr/share/doc/gnome-pkg-tools/README.Debian.gz :

Copy control to control.in so that it gets refreshed before each build

Make the following edits:
Build-Depends: ..., gnome-pkg-tools
Uploaders: @GNOME_TEAM@

See 
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-collaborative-maint
 :

"In any case, it is a bad idea to automatically put all team members in
the Uploaders field. It clutters the Developer's Package Overview
listing (see Developer's packages overview, Section 4.11) with packages
one doesn't really care for, and creates a false sense of good
maintenance."

I think that the former is easy to use, so that's nice, but as the team
memberships continuously changes, the value of "Uploaders:" gets
outdated very easily.

I think that the latter is very true.  It feels better to me to only
include names of maintainers really contributing to the packages, so
that implies a different set of "Uploaders:" per package maintained by
the team.  It more accurately reflects who's caring about the packages.

Other opinions?

Regards,

Bart Martens



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



Re: use of "Uploaders:" field for team maintained packages

2007-10-20 Thread Francesco P. Lovergine
On Sat, Oct 20, 2007 at 09:02:02AM +0200, Bart Martens wrote:
> I think that the latter is very true.  It feels better to me to only
> include names of maintainers really contributing to the packages, so
> that implies a different set of "Uploaders:" per package maintained by
> the team.  It more accurately reflects who's caring about the packages.
> 

I agree, but how managing this thing is a team policy. In DebianGis
we also remove uploaders after a reasonable period of non-contributing
time.

-- 
Francesco P. Lovergine


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



Re: Bits from the Security Team

2007-10-20 Thread Lars Wirzenius

pe, 2007-10-19 kello 18:29 +0200, Adrian von Bidder kirjoitti:
> Seriously:  I think exactly this kind of "not really much new stuff going 
> on, but here's what we're continuing to do" kind of information should be 
> more visible, because it, too, is valuable information to somebody who is 
> not involved tightly in the Debian teams.

Aye. In many corporations, a weekly or monthly status report is required
from employees. I don't think we want to make it a requirement, but I do
think the "Bits from" mails are a great thing, and getting them, say,
monthly would be very nice, even if they just say "business as usual,
Steve still likes pies". So please take this as encouragement if you're
thinking about whether you or your team should send more of them. :)

I appreciate that writing such mails takes effort. That's one of the
reasons I don't think we can or should require them, but even
lightweight ones are useful.

-- 
You need fewer comments, if you choose your names carefully.


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



Re: use of "Uploaders:" field for team maintained packages

2007-10-20 Thread Loïc Minier
On Sat, Oct 20, 2007, Bart Martens wrote:
> I'm surprised that /usr/share/doc/gnome-pkg-tools/README.Debian.gz
> contradicts with the good practices described in developers reference.
[...]
>It feels better to me to only
> include names of maintainers really contributing to the packages, so
> that implies a different set of "Uploaders:" per package maintained by
> the team.

 This is how the current gnome-pkg-tools rules behave; the Uploaders
 field will list the intersection of the team and recent uploaders
 (looking at the changelog) of the package.  Other features are that the
 team's ML is also always added to Uploaders: and the Maintainer: is
 always filtered out of Uploaders.

 This was done in March, so only packages built against gnome-pkg-tools
 0.11 or later will get such uploaders.

-- 
Loïc Minier


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



how to find out the sponsor of an upload?

2007-10-20 Thread Hamish Moffatt
How can I find out who sponsored a particular upload? (I only need to do
it by hand, not an automated lookup.)

I expected that I could locate the upload announcement on
debian-devel-changes, then verify the signature to get the key ID, and
look that up. I got a key ID, but can't find out whose it is, suggesting
it's not in the keyring... Now I'm confused.

It would be useful if this information was recorded somewhere,
especially as dak has to verify the key on uploads anyway.


As an aside, db.debian.org only allows searching by whole fingerprint, not 
key ID.


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


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



Re: how to find out the sponsor of an upload?

2007-10-20 Thread Loïc Minier
On Sat, Oct 20, 2007, Hamish Moffatt wrote:
> How can I find out who sponsored a particular upload?

 Check the who-uploads helper in devscripts.

-- 
Loïc Minier


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



Re: how to find out the sponsor of an upload?

2007-10-20 Thread Felipe Sateler
Hamish Moffatt wrote:

> How can I find out who sponsored a particular upload? (I only need to do
> it by hand, not an automated lookup.)
> 
> I expected that I could locate the upload announcement on
> debian-devel-changes, then verify the signature to get the key ID, and
> look that up. I got a key ID, but can't find out whose it is, suggesting
> it's not in the keyring... Now I'm confused.

the debian-keyring package has not been updated in more than 2 years. You
need to rsync the actual keyring from keyring.debian.org::keyrings if you
want to know who uploaded.

> 
> It would be useful if this information was recorded somewhere,
> especially as dak has to verify the key on uploads anyway.

If you have a recent keyring, then who-uploads will show you that
information.

> 
> 
> As an aside, db.debian.org only allows searching by whole fingerprint, not
> key ID.
> 
> 
> thanks
> Hamish

-- 

  Felipe Sateler


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



Re: Firefox bugs mass-closed.

2007-10-20 Thread peter green

We encourage people to not file duplicate bug reports, and check the BTS
first. So I check the BTS, the bug is there, I don't file a new one (I
do send a "me too"). 6 weeks later, the bug is closed because the
submitter's email is bouncing and he's on vacation anyway.
It sounds like what is really required is the ability for a bug to have multiple 
"reporters" recorded. Then any queries about a bug can be sent to all the 
reporters not just the one who happened to submit the report first.




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



Re: how to find out the sponsor of an upload?

2007-10-20 Thread Bernd Zeimetz
Hi,

> How can I find out who sponsored a particular upload? (I only need to do
> it by hand, not an automated lookup.)

My favorite way is to go to the maintainer's qa page,
http://qa.debian.org/developer.php?login=hamish for example, move the
mouse over the version number and look at the tooltip which shows up
after a few seconds.

Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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



Bug#447393: RFA: bins -- Generate static HTML photo albums using XML and EXIF tags

2007-10-20 Thread Ludovic Rousseau
Package: wnpp
Severity: normal

Hello,

I do not use bins anymore.
The co-maintainer, Martin Michlmayr, do not have time to maintain it
either.

Debian bugs have been formwared upstream at
https://gna.org/bugs/?group=bins but none were ever answered.
It looks like bins has been orphaned upstream.

If you want it please take it.

Regards,

Package info:
Description: Generate static HTML photo albums using XML and EXIF tags
 BINS generates a complete static gallery (images and HTML) with
 thumbnails and image lists, using XML files to hold information about
 each image.  Includes bins_edit and bins-edit-gui tools for adding
 information to the XML files.  Interprets EXIF and JFIF tags (and
 Canon extensions) in the jpeg directly.  Gallery appearance
 customizable through HTML templates; gallery can be generated in
 different languages.
 .
 Based on SWIGS (Structured Web Image Gallery System).
 .
  Homepage: http://bins.sautret.org/



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

Kernel: Linux 2.6.22-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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



Re: Firefox bugs mass-closed.

2007-10-20 Thread Roberto C . Sánchez
On Sat, Oct 20, 2007 at 05:15:51PM +0100, peter green wrote:
> >We encourage people to not file duplicate bug reports, and check the BTS
> >first. So I check the BTS, the bug is there, I don't file a new one (I
> >do send a "me too"). 6 weeks later, the bug is closed because the
> >submitter's email is bouncing and he's on vacation anyway.
> It sounds like what is really required is the ability for a bug to have 
> multiple "reporters" recorded. Then any queries about a bug can be sent to 
> all the reporters not just the one who happened to submit the report first.
> 
Just curious, but what benefit would this provide?

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature


Re: Debian Menu transition status

2007-10-20 Thread Andreas Tille
On Tue, 9 Oct 2007, Bill Allombert wrote:

> Others changes:
> ===
>
> -- Menu support a new format called "menu-2" since 8 years.

Uhmmm, this is one of the strangest sentences I read on this list this
year.  At which time scale you would regard eight years old as new (at
least in the world of computers)?  I would rather pronounce:

  The menu format that is currently used by nearly every package
  was obsolated by the menu-2 format two years ago because the
  information about was so perfectly hidden that nobody really
  noticed.

I base my assumption that nobody really noticed on the fact that

grep "menu-2" /usr/share/menu/*

revealed no result on my machine.

> In this
> format lines break are not significant, but logical lines end by a
> semi-comma:
>
> This is an example:
>
> !C menu-2
> ?package(pari-gp):
>  section="Applications/Science/Mathematics"
>  needs="text"
>  title="PARI/GP"
>  command="gp"
> ;
>
> I do not have strong opinion about this format, but feel free to use it.

Well, the strongest prove that you are not alone is that neither
debian-policy mentions it (see #447389), nor dh-make creates menu-2
templates (see #447390) nor lintian suggests this format (see #447391).
But how should we interpret the sentence below:

> Since even potato support menu-2, there are no upgrade or backport
> issue, however this might break the lintian code to parse menu file.
>
> menu-2 is also available for menu-methods, through the definition
> compat="menu-2". I highly recommend its use for menu-methods.

So you highly recommend something you have no feelings about?
What is the sense of inventing a format and not providing any
information about it.  Even grepping through /usr/share/doc/menu/html
revealed only some notes amout menu-2 but no code example locked
like above.  The manual claims to describe menu format menu-2
but considering that the code uses backspace '\' which should be
necessary according to the information above and given that the
line "!C menu-2" is mandatory as well as the final semicolon
in contrast to the statement of /usr/share/doc/menu/html/ch1.html
that this document describes the menu-2.0 format this is just
not the case (and I should probably a file against the menu
package about this).

So how could you expect developers to adopt a new format if there
is no information about it?

> Imagine a large red swirl here.

I have to admit that my brain turned in a multi colored huge
swirl when I finaly was pointed to this information which was
hidden in the very end of a long mail that was posted to
debian-devel-announce (but got archived on debian-devel strangely
enough).

After settling down with this I wonder whether you could easily
turn a menu-1 format file into a menu-2 format file by just
wrapping it i between

   !C menu-2
   
   ;

or is there some other magic?

Kind regards

 Andreas.


-- 
http://fam-tille.de


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



Linux stuck when serial cable is disconnected

2007-10-20 Thread hagit
Hi all,
I am running on a MIPS machine, with my kernel and debian distribution
(file system).
The kernel messages are configured to get out from the serial
connection, i.e. serial console.
When the serial output of my MIPS is connected to my PC everything is
OK and I can see the outputs in the terminal.
When I disconnect the serial cable my Linux get stuck. Even my telnet
connection doesnt responds.
When I re-connect the serial everything is OK again.
Do you know what can be the problem?
I am working with HW flow control? can it be the problem?

Thanks a lot!
Hagit


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



Re: Processing of haskell-x11-extras_0.4-1.1_i386.changes

2007-10-20 Thread Joachim Breitner
Hi,

I just got this message, and I don’t know what to do with it. I uploaded
haskell-x11-extras_0.4-1_i386.changes to NEW a while ago, and it’s still
there. Maybe some buildd? Or did someone try to sneak in a package?

Greetings,
Joachim

Am Samstag, den 20.10.2007, 00:22 + schrieb Archive Administrator:
> PGP/GnuPG signature check failed on haskell-x11-extras_0.4-1.1_i386.changes
> gpg: Signature made Sat Oct 20 00:17:43 2007 UTC using DSA key ID BF45DCE3
> gpg: Can't check signature: public key not found
> gpg: Signature made Sat Oct 20 00:17:43 2007 UTC using DSA key ID BF45DCE3
> gpg: Can't check signature: public key not found
> (Exit status 2)
> haskell-x11-extras_0.4-1.1_i386.changes has bad PGP/GnuPG signature!
> Removing haskell-x11-extras_0.4-1.1_i386.changes, but keeping its associated 
> files for now.
> 
> Greetings,
> 
>   Your Debian queue daemon
> 
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata



Re: Bits from the Security Team

2007-10-20 Thread Steve Kemp
On Sat Oct 20, 2007 at 12:00:23 +0300, Lars Wirzenius wrote:
> 
> pe, 2007-10-19 kello 18:29 +0200, Adrian von Bidder kirjoitti:
> > Seriously:  I think exactly this kind of "not really much new stuff going 
> > on, but here's what we're continuing to do" kind of information should be 
> > more visible, because it, too, is valuable information to somebody who is 
> > not involved tightly in the Debian teams.
> 
> I do think the "Bits from" mails are a great thing, and getting them, say,
> monthly would be very nice, even if they just say "business as usual,
> Steve still likes pies".

   I agree.  I like reading them myself, which is why I posted my
  little entry with the subtitle I did.

Steve
--


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



Re: Bits from the Security Team

2007-10-20 Thread Steve Kemp
On Fri Oct 19, 2007 at 18:29:46 +0200, Adrian von Bidder wrote:

> That you like pies is important.

  :)

> Though in the specific case of the security team, the flow of security
> updates is an indication that the team is working

  Yes, this is what I think too.

> Could've cc:ed you at least.  Apologies.

  No problem.

Steve
-- 


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



Re: Linux stuck when serial cable is disconnected

2007-10-20 Thread Ben Pfaff
hagit <[EMAIL PROTECTED]> writes:

> I am running on a MIPS machine, with my kernel and debian distribution
> (file system).
> The kernel messages are configured to get out from the serial
> connection, i.e. serial console.
> When the serial output of my MIPS is connected to my PC everything is
> OK and I can see the outputs in the terminal.
> When I disconnect the serial cable my Linux get stuck. Even my telnet
> connection doesnt responds.

My guess is that syslogd is blocking on a write to the serial
port, and other software is blocking on sending a log message to
syslogd.
-- 
Ben Pfaff 
http://benpfaff.org


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



Changes in the xine-lib package require changes in xine-frontends

2007-10-20 Thread Reinhard Tartler

Dear maintainers of xine-frontends,

You are receiving this email because you are maintaining a package that
build-depends on libxine-dev, a popular media player. In order to fix the RC
bug #439389, a reorganisation of the xine package has been made. This
reorganisation has effects on xine-lib's frontends.

In Detail: The next upload of libxine1 will contain nearly no plugins,
which makes the package for its own pretty unusable for anything but
building plugins. The libxine1 package now has a dependency
on libxine1-plugins | libxine1-misc-plugins. The former package itself
depends on all plugins a user would normally expect to have installed
for general multimedia use: this includes the libxine1-misc-plugins
package, which ships most of the plugins previously in libxine1, with
the rest having been moved into libxine1-x or libxine1-console. The only
video output plugin in libxine1-misc-plugins is "none".

There are two remaining packages: libxine1-x and libxine1-console. These two
packages are not depended on by other packages from xine-lib. Instead, the
frontend packages (this means a package that you maintain) is expected to
depend on either libxine1-x or libxine1-console, depending on if your
frontend is X-based or text-only/framebuffer-based.

It is perfectly possible that you are receiving this message in error, e.g.
if you are maintaining just a package that provides an additional xine-lib
plugin. In this case, please ignore this mail.

This change is about to happen in xine-lib_1.1.8-2. Due to the addition
of the new packages libxine1-x and libxine1-misc-plugins, the package
will have to be approved by an ftp-master before acceptance into
unstable. Please prepare yourself to reupload your package with adjusted
dependencies at your earliest convenience after the new libxine1 package
appears in unstable.

Thanks for your cooperation,
your xine-lib maintainers


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


pgpLqEF2pWaf9.pgp
Description: PGP signature


Bug#439389: Info received (Changes in the xine-lib package require changes in xine-frontends)

2007-10-20 Thread Debian Bug Tracking System
Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the package maintainer(s)
and to other interested parties to accompany the original report.

Your message has been sent to the package maintainer(s):
 Reinhard Tartler <[EMAIL PROTECTED]>

If you wish to continue to submit further information on this problem,
please send it to [EMAIL PROTECTED], as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Debian bug tracking system administrator
(administrator, Debian Bugs database)



Bug#447410: ITP: libmowgli -- Development framework for C

2007-10-20 Thread Adam Cécile (Le_Vert)
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: libmowgli
Version: 0.5.0
Upstream Author: Atheme Project
URL: http://www.atheme-project.org/projects/mowgli.shtml
License: ISC
Description:
Mowgli is a development framework for C (like GLib), which provides high
performance and highly flexible algorithms.
.
It can be used as a suppliment to GLib (to add additional functions
(dictionaries, hashes), or replace some of the slow GLib list manipulation
functions), or stand alone.
.
It also provides a powerful hook system and convenient logging for your
code, as well as a high performance block allocator.




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



Re: Firefox bugs mass-closed.

2007-10-20 Thread Raphael Geissert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

peter green wrote:
> It sounds like what is really required is the ability for a bug to have
> multiple "reporters" recorded. Then any queries about a bug can be sent to
> all the reporters not just the one who happened to submit the report
> first.

Why multiple reporters? you can subscribe to a bug report by sending an
email to [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHGogjYy49rUbZzloRAl36AJ4t0RYHjqQQQUJDFcfei6Ntk1IwygCfWiA7
S9lpyPOl+rptP2CtfN8cvo8=
=TZiB
-END PGP SIGNATURE-


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



Re: how to find out the sponsor of an upload?

2007-10-20 Thread Hamish Moffatt
On Sat, Oct 20, 2007 at 01:17:36PM -0300, Felipe Sateler wrote:
> Hamish Moffatt wrote:
> > How can I find out who sponsored a particular upload? (I only need to do
> > it by hand, not an automated lookup.)
> > 
> > I expected that I could locate the upload announcement on
> > debian-devel-changes, then verify the signature to get the key ID, and
> > look that up. I got a key ID, but can't find out whose it is, suggesting
> > it's not in the keyring... Now I'm confused.
> 
> the debian-keyring package has not been updated in more than 2 years. You
> need to rsync the actual keyring from keyring.debian.org::keyrings if you
> want to know who uploaded.
> 
> > It would be useful if this information was recorded somewhere,
> > especially as dak has to verify the key on uploads anyway.
> 
> If you have a recent keyring, then who-uploads will show you that
> information.

Excellent. Thanks all for the information. The DDPO method is also
useful (although it only reveals the login of the uploader, so a visit
to db.d.o is often required).

devscripts rocks. Thanks Julian.

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


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



Re: Firefox bugs mass-closed.

2007-10-20 Thread Don Armstrong
On Sat, 20 Oct 2007, peter green wrote:
>> We encourage people to not file duplicate bug reports, and check the BTS
>> first. So I check the BTS, the bug is there, I don't file a new one (I
>> do send a "me too"). 6 weeks later, the bug is closed because the
>> submitter's email is bouncing and he's on vacation anyway.
> It sounds like what is really required is the ability for a bug to have 
> multiple "reporters" recorded. Then any queries about a bug can be sent to 
> all the reporters not just the one who happened to submit the report first.

If you want that, just subscribe to the bug.

Submitters as it is now do not automatically receive all messages
regarding a bug.


Don Armstrong

-- 
No matter how many instances of white swans we may have observed, this
does not justify the conclusion that all swans are white.
 -- Sir Karl Popper _Logic of Scientific Discovery_

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


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



Bug#447414: ITP: filelight-i18n -- Intenationalization (i18n) for Filelight, disk space usage tool

2007-10-20 Thread Raúl Sánchez Siles
Package: wnpp
Severity: wishlist
Owner: "Raúl Sánchez Siles" <[EMAIL PROTECTED]>

* Package name: filelight-i18n
  Version : 1.0-1
  Upstream Author : Max Howell <[EMAIL PROTECTED]>
* URL : http://www.methylblue.com/filelight/
* License : (GPL)
  Programming Lang: (C++)
  Description : Intenationalization (i18n) for Filelight, disk space usage 
tool

 This package provides internationalization (i18n) files (translations) for
 Filelight, Filelight allows you to understand your disk usage by graphically
 representing your filesystem as a set of concentric, segmented rings.
 
 See the 'filelight' package description for more information.
 
 Homepage: http://www.methylblue.com/filelight/

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

Kernel: Linux 2.6.22rs (SMP w/1 CPU core)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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



Re: how to find out the sponsor of an upload?

2007-10-20 Thread Raphael Geissert
Hamish Moffatt wrote:

> On Sat, Oct 20, 2007 at 01:17:36PM -0300, Felipe Sateler wrote:
> 
> Excellent. Thanks all for the information. The DDPO method is also
> useful (although it only reveals the login of the uploader, so a visit
> to db.d.o is often required).

Just query finger [EMAIL PROTECTED]

> 
> devscripts rocks. Thanks Julian.
> 
> Hamish



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



Re: Changes in the xine-lib package require changes in xine-frontends

2007-10-20 Thread Daniel Baumann
Reinhard Tartler wrote:
> This change is about to happen in xine-lib_1.1.8-2. Due to the addition
> of the new packages libxine1-x and libxine1-misc-plugins, the package
> will have to be approved by an ftp-master before acceptance into
> unstable. Please prepare yourself to reupload your package with adjusted
> dependencies at your earliest convenience after the new libxine1 package
> appears in unstable.

Can you please upload it somewhere else too, so that we can have a look
at it before it leaves NEW? That would be very nice.

Regards,
Daniel

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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



Re: Bug#447414: ITP: filelight-i18n -- Intenationalization (i18n) for Filelight, disk space usage tool

2007-10-20 Thread Christian Perrier
Quoting Raúl Sánchez Siles ([EMAIL PROTECTED]):
> Package: wnpp
> Severity: wishlist
> Owner: "Raúl Sánchez Siles" <[EMAIL PROTECTED]>
> 
> * Package name: filelight-i18n
>   Version : 1.0-1
>   Upstream Author : Max Howell <[EMAIL PROTECTED]>
> * URL : http://www.methylblue.com/filelight/
> * License : (GPL)
>   Programming Lang: (C++)
>   Description : Intenationalization (i18n) for Filelight, disk space 
> usage tool
> 
>  This package provides internationalization (i18n) files (translations) for


If the package provides translations, this is a *localization* package
and I therefore recommend naming it "filelight-l10n"

Unfortunately, many packages in Debian did not implement that logic
(the most proeminent being KDE packages) and we equally have -i18n
packages and -l10n ones..:-(but that's not a reason for repeating
the mistake.



signature.asc
Description: Digital signature