Re: openexp

2006-08-30 Thread Filippo Giunchedi
On Wed, Aug 09, 2006 at 03:29:08PM +0200, Marco d'Itri wrote:
 www.openexp.it
 
 29-30 Settembre e 1 Ottobre 2006.
 Come era webbit una volta, ma meno commerciale.
 
 Ci sarà abbastanza gente, sarebbe utile riuscire ad organizzare uno
 stand di Debian.

potrebbero fare comodo queste due paginette del wiki:

http://wiki.debian.org/DebianEventsHowto
http://wiki.debian.org/DebianEventsFaqs

Marco: non ho capito se siamo gia' registrati come associazione/stand/qualcosa o
dobbiamo muoverci per la partecipazione.

filippo



Re: openexp

2006-08-30 Thread Marco d'Itri
On Aug 30, Filippo Giunchedi [EMAIL PROTECTED] wrote:

 Marco: non ho capito se siamo gia' registrati come 
 associazione/stand/qualcosa o
 dobbiamo muoverci per la partecipazione.
Dobbiamo muoverci perché se lo confermiamo abbiamo la disponibilità di
uno stand ma nessuno si è fatto avanti per coordinare la cosa.
(Idem per Ubuntu, se a qualcuno interessa.)

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: openexp

2006-08-30 Thread Marco Bertorello
On Wed, 30 Aug 2006 13:15:54 +0200
Filippo Giunchedi [EMAIL PROTECTED] wrote:

 On Wed, Aug 30, 2006 at 12:08:30PM +0200, Marco d'Itri wrote:
  On Aug 30, Filippo Giunchedi [EMAIL PROTECTED] wrote:
  
   Marco: non ho capito se siamo gia' registrati come
   associazione/stand/qualcosa o dobbiamo muoverci per la
   partecipazione.
  Dobbiamo muoverci perché se lo confermiamo abbiamo la disponibilità
  di uno stand ma nessuno si è fatto avanti per coordinare la cosa.
 
 ok, io di materiale debian non ho nulla (una polo a dire il vero, ma
 e' mia :)) qualcuno ce l'ha dagli scorsi eventi e pensa di
 partecipare? altrimenti bisogna trovare un modo di avere i materiali
 in loco.

Se avanza qualche maglietta debian dalla DCCIT (che sta preparando
Silvano Sartore,anche se non ho più news da tempo), si possono
utilizzare per openexp

 da quello che ho capito saremmo:
 
 io
 enrico
 md (?)
 christian surchi (?)

Non sono sicuro ancora di riuscire a partecipare, sorry :-(

-- 
Marco Bertorello
System Administrator
http://bertorello.ns0.it


signature.asc
Description: PGP signature


Re: openexp

2006-08-30 Thread Marco Bertorello
On Wed, 30 Aug 2006 13:15:54 +0200
Filippo Giunchedi [EMAIL PROTECTED] wrote:

 On Wed, Aug 30, 2006 at 12:08:30PM +0200, Marco d'Itri wrote:
  On Aug 30, Filippo Giunchedi [EMAIL PROTECTED] wrote:
  
   Marco: non ho capito se siamo gia' registrati come
   associazione/stand/qualcosa o dobbiamo muoverci per la
   partecipazione.
  Dobbiamo muoverci perché se lo confermiamo abbiamo la disponibilità
  di uno stand ma nessuno si è fatto avanti per coordinare la cosa.
 
 ok, io di materiale debian non ho nulla (una polo a dire il vero, ma
 e' mia :)) qualcuno ce l'ha dagli scorsi eventi e pensa di
 partecipare? altrimenti bisogna trovare un modo di avere i materiali
 in loco.

Se avanza qualche maglietta debian dalla DCCIT (che sta preparando
Silvano Sartore,anche se non ho più news da tempo), si possono
utilizzare per openexp

 da quello che ho capito saremmo:
 
 io
 enrico
 md (?)
 christian surchi (?)

Non sono sicuro ancora di riuscire a partecipare, sorry :-(

-- 
Marco Bertorello
System Administrator
http://bertorello.ns0.it


signature.asc
Description: PGP signature


Re: openexp

2006-08-30 Thread Stefano Melchior
On Wed, Aug 30, 2006 at 02:22:34PM +0200, Marco Bertorello wrote:
Ciao a tutti,
Marco: non ho capito se siamo gia' registrati come
associazione/stand/qualcosa o dobbiamo muoverci per la
partecipazione.
   Dobbiamo muoverci perché se lo confermiamo abbiamo la disponibilità
   di uno stand ma nessuno si è fatto avanti per coordinare la cosa.
  
  ok, io di materiale debian non ho nulla (una polo a dire il vero, ma
  e' mia :)) qualcuno ce l'ha dagli scorsi eventi e pensa di
  partecipare? altrimenti bisogna trovare un modo di avere i materiali
  in loco.
mi piacerebbe dare una mano, penso di poterci essere il sabato, magari
posso dare una mano allo stand.
Stavo pensando di proporre un talk su UML (User Mode Linux), per chi fosse
interessato... e sempre che agli organizzatori interessi.
 
 Se avanza qualche maglietta debian dalla DCCIT (che sta preparando
 Silvano Sartore,anche se non ho più news da tempo), si possono
 utilizzare per openexp
A presto

SteX
-- 
Stefano Melchior, GPG key = D52DF829 - [EMAIL PROTECTED]
http://www.openlabs.it/~stex-- [EMAIL PROTECTED]
http://etinarcadiaego.dyndns.org  --  [EMAIL PROTECTED]
Skype ID stefanomelchior


signature.asc
Description: Digital signature


Re: Why does Ubuntu have all the ideas? Debian official update sub-release

2006-08-30 Thread Martin Schulze
John Goerzen wrote:
 On Mon, Aug 28, 2006 at 05:09:54PM +0200, Joey Schulze wrote:
  ciol wrote:
   The problem is that Debian doesn't speak a lot about nice features like
   volatile and backports, for instance in the official web site, where it's
   difficult to see the links.
  
  The... err... issue is that these services (snapshots, volatile, backports)
  are not official project's projects yet and also quite new, hence, not
  integrated in the current stable installer.  It is discussed to change
  this though.  You are correct, though, that they're not widely announced.

 As it is, it is unclear to me who is building those packages, of what
 quality they are, and what kind of security support they are receiving.

It's Debian developers.  They're updated occasionally.  Security updates
are pulled into both archives in similar timeframes like security.debian.org,
sometimes even faster since not that many architectures are involved.

Regards,

Joey

-- 
Have you ever noticed that General Public Licence contains the word Pub?

Please always Cc to me when replying to me on the lists.


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Raphael Hertzog
On Wed, 30 Aug 2006, Mike Hommey wrote:
 On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek [EMAIL PROTECTED] 
 wrote:
  On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote:
  
   Debian needs to make a decision on how it will deal with this legal
   minefield.  That is higher priority than the entire discussion going on
   right now, because it determines whether Debian will distribute these 53
   BLOBs *at all*, in 'main' or in 'non-free'.
  
   Oddly enough nobody has proposed a GR addressing this,
  
  Because voting is an absurd means of settling questions of legal liability.
  It's the domain of the ftp team to determine whether we can legally
  distribute a package on our mirrors.
 
 So, all in all, all this fuss for seven blobs ? waw, what a waste of
 time.

53 + 7 = 60.

Please Mike, you have lately a tendency to inflame discussions for
nothing. You've used me to expect better from you.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Marco d'Itri
On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote:

 Debian must decide whether it wants to ship BLOBs with licensing which
 technically does not permit redistribution.  At least 53 blobs have this
 problem.  Many of them are licensed under the GPL, but without source code
 provided.  Since the GPL only grants permission to distribute if you
 provide source code, the GPL grants no permission to distribute in these
 cases.
Many people disagree with this interpretation.

 Oddly enough nobody has proposed a GR addressing this, and Debian continues
 to ship 47 improperly licensed files in linux-2.6.  If I were SCO, I'd buy
 up the copyrights to them from the original companies, and then I'd have a
 real case for a lawsuit.
Not really. What effects do you think a lawsuit about this would have?

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Sven Luther
On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote:
 On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote:
 
  Debian must decide whether it wants to ship BLOBs with licensing which
  technically does not permit redistribution.  At least 53 blobs have this
  problem.  Many of them are licensed under the GPL, but without source code
  provided.  Since the GPL only grants permission to distribute if you
  provide source code, the GPL grants no permission to distribute in these
  cases.
 Many people disagree with this interpretation.

A few very vocal people do. I guess they can be counted on the fingers of both
hands or so.

Friendly,

Sven Luther


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



Re: Policy regarding virtual packages

2006-08-30 Thread Magnus Holmgren
On Wednesday 30 August 2006 00:29, Steve Langasek took the opportunity to say:
 On Tue, Aug 29, 2006 at 01:51:39PM +0200, Magnus Holmgren wrote:
  On Monday 28 August 2006 21:06, Steve Langasek took the opportunity to 
say:
   On Mon, Aug 28, 2006 at 04:01:57PM +0200, Magnus Holmgren wrote:
Making mail-transport-agent the empty package, and having it depend
only on exim4 (the default), should work. Of course, exim4 can't
conflict with it (but it's enough that all the others do),
  
   No, that's not enough.  The exim4 package has file conflicts with the
   other implementors of m-t-a; there need to be Conflicts declared
   *directly* between exim4 and the others.
 
  So package-a conflicts package-b is not the same thing as package-a
  conflicts package-b AND package-b conflicts package-a? The policy seems
  to be saying that if a package conflicts with another package
  (asymmetric), then they can't be installed at the same time (symmetric).

 What I understood was being discussed was a situation where package-a
 depends package-b, package-a conflicts package-c, and package-b and
 package-c have conflicts at the filesystem level.

Aha. No, package-c conflicts package-b as well. We would have (for example):

Package: mail-transfer-agent
Depends: exim4

Package: exim4
Provides: mail-transfer-agent
Replaces: mail-transfer-agent (??)

Package: postfix
Provides: mail-transfer-agent
Conflicts: mail-transfer-agent
Replaces: mail-transfer-agent

Anyway, this looks a bit ugly.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpe1muqeru91.pgp
Description: PGP signature


Re: The bigger issue is badly licensed blobs (was Re:Firmware poll

2006-08-30 Thread Pierre HABOUZIT
On Wed, Aug 30, 2006 at 09:00:27AM +0200, Raphael Hertzog wrote:
 On Wed, 30 Aug 2006, Mike Hommey wrote:
  On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek [EMAIL 
  PROTECTED] wrote:
   On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote:
   
Debian needs to make a decision on how it will deal with this legal
minefield.  That is higher priority than the entire discussion going on
right now, because it determines whether Debian will distribute these 53
BLOBs *at all*, in 'main' or in 'non-free'.
   
Oddly enough nobody has proposed a GR addressing this,
   
   Because voting is an absurd means of settling questions of legal 
   liability.
   It's the domain of the ftp team to determine whether we can legally
   distribute a package on our mirrors.
  
  So, all in all, all this fuss for seven blobs ? waw, what a waste of
  time.
 
 53 + 7 = 60.
 
 Please Mike, you have lately a tendency to inflame discussions for
 nothing. You've used me to expect better from you.

  this dig is obviously meant to calm things down…

  Not to mention that *you* are wrong and that Mike is right, there is
currently only 7 blob's that we can suppose to be distributable and
sourceless at the same time. Mike's frustration cry would have been
unoticed if you hadn't felt compelled to slosh your sanctimonious oil
all over the fire.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


signature.asc
Description: Digital signature


Re: The bigger issue is badly licensed blobs (was Re:Firmware poll

2006-08-30 Thread Steve Langasek
On Wed, Aug 30, 2006 at 10:22:38AM +0200, Pierre HABOUZIT wrote:
   So, all in all, all this fuss for seven blobs ? waw, what a waste of
   time.

  53 + 7 = 60.

  Please Mike, you have lately a tendency to inflame discussions for
  nothing. You've used me to expect better from you.

   this dig is obviously meant to calm things down…
 
   Not to mention that *you* are wrong and that Mike is right

No, he's not.  There are 60 sourceless blobs that we would potentially
redistribute in main depending on the outcome of this discussion.  This
depends on the answer to two questions: does the project consider it ok to
include sourceless firmware in main, and does the ftp team believe it's ok
to distribute sourceless firmware that is claimed to be under the GPL?  Only
the first question belongs to debian-vote, and it's one we should try to get
answered regardless of the answer to the second -- because for those 53
other pieces of firmware, if the ftpmasters *do* decide we need a better
license, the most likely outcome of contacting upstreams would be that they
give us a better license and *still* don't give us the source.

And in any case, posting to complain that you think a particular issue isn't
worth having a GR about is hardly a productive use of anyone's time.

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


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



Re: Debian ISOs

2006-08-30 Thread Subredu Manuel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Josselin Mouette wrote:
 Le jeudi 17 août 2006 à 11:48 -0400, Anthony L. Bryan a écrit :
 
 Given that downloads like Debian ISOs are already putting a heavy
 bandwidth load on the servers and that they are already shared among
 many servers, I don't think it is a good idea to encourage users to load
 several servers at once with one download. We should instead push
 bittorrent as the main distribution media for ISOs.

 I don't think you got the picture. Metalink can contain information for
download using the following protocols:
 *) http
 *) ftp
 *) bittorrent
 *) e2k

Also, magnet url's can be included. What protocol is used to download
the files, remains to users choice. IMHO, either if you use metalinks or
not, the user can still choose to use http/ftp/torrent/e2k/ without you
to approve that.
 The main advantage in using metalinks is that all information about
downloading files using different protocols are included in _one file_
and the user has to choose which one to use.
 And related to mirrors. What's the purpose of the mirrors ? To reduce
the load on the main servers and to help in better distribution files.
Agree ? Let's see now. What does metalink does ? Permit the use of _all
mirrors_ and better, permit the average Joe to download the images
faster. How do you know that the bittorrent is the logical choice ? Just
becase the protocol is great for distributing large files ? How do you
known that some area of China (for example) does not use e2k as their
primary download protocol ? Just think that in this moment, metalink
provides the user the most complete information for downloading a file.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE9VHljGXbUSvc3AsRAngGAJ9N7AxjO/3qbTRZM2alaM81JPN9yQCfUB23
MOEc/gmgtqBrLebg4A+8Nxk=
=DI3k
-END PGP SIGNATURE-


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Mike Hommey
On Wed, Aug 30, 2006 at 09:00:27AM +0200, Raphael Hertzog wrote:
 On Wed, 30 Aug 2006, Mike Hommey wrote:
  On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek [EMAIL 
  PROTECTED] wrote:
   On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote:
   
Debian needs to make a decision on how it will deal with this legal
minefield.  That is higher priority than the entire discussion going on
right now, because it determines whether Debian will distribute these 53
BLOBs *at all*, in 'main' or in 'non-free'.
   
Oddly enough nobody has proposed a GR addressing this,
   
   Because voting is an absurd means of settling questions of legal 
   liability.
   It's the domain of the ftp team to determine whether we can legally
   distribute a package on our mirrors.
  
  So, all in all, all this fuss for seven blobs ? waw, what a waste of
  time.
 
 53 + 7 = 60.

Re-read Nathanael's mail. The blobs that are concerned by all the discussion
that has happened so far, and wasted a lot of time, are 7.

The 53 are those that have licenses that technically don't allow
redistribution.

 Please Mike, you have lately a tendency to inflame discussions for
 nothing. You've used me to expect better from you.

I'm just pissed about all this waste of time discussing in the void while
a release is supposed to happen in 3 months. And here I'm not only talking
about this particular thread.

Mike

PS: Don't worry, you won't hear a lot from me since I'll be on vacation from
saturday for almost 3 weeks.


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



How to package OTF CID fonts?

2006-08-30 Thread Arne Götje (高盛華)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi list,

I'm developing a set of Pan-CJK CID fonts (OTF/TTF format, not wrapped
up PS),
which will come with their own font specific CMap files. The Adobe ones
won't work.

Now my question: Where should the fonts and the CMap files be installed and
how to register them in the system, so that most applications will be
able to use them?

Any hints/pointers on defoma, fontconfig, xorg, etc.?
Any example configs out there?

Cheers
Arne
- --
Arne Götje (高盛華) [EMAIL PROTECTED]
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F  1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE9V6Nbp/QbmhdHowRAt56AJ9ZbgytnBe1sddUVDLV8f3/a0HGdQCfd/QP
Pb73Z3NcQqIFNuUaJP8jFcc=
=exb9
-END PGP SIGNATURE-


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



Re: inet-superserver virtual package

2006-08-30 Thread Guillem Jover
On Mon, 2006-08-28 at 12:27:43 +0200, Marco d'Itri wrote:
 On Aug 28, Guillem Jover wrote:
  Just yesterday night dato raised the issue on #d-release, and I was
  telling about the virtual package, and that we could move to it now,
  and worry later about a possible transition to that new update-inetd
  (if it happens to exist some day), aj was fine with that.

 OK, but then let's do it right.
 The idea is to move update-inetd from netbase to each one of the inetd
 packages (openbsd-inetd, inetutils-inetd, rlinetd, xinetd), which will
 provide the inet-superserver virtual package and depend on a version of
 netbase which does not have update-inetd (is a Replaces needed too?).

I'm not convinced that duplicating update-inetd in most of the
inetd providing packages is a good idea, even if this would allow
xinetd to be able to replace a normal inetd easily. I'd prefer that the
odd cases override update-inetd, via a custom script that gets called
if present from u-i or replace it or whatever.

Also in case the mythical rewrite happens it will be easier to
coordinate just one instance than all of them, or to sync them if
people start fixing their instances.

 netbase then will temporarily depend on inet-superserver to allow smooth
 upgrades until the other packages will switch to a dependency on the
 virtual package[1][2].

Do you mean only a depedency to the virtual package, w/o a real one?

 [2] At the same point we should argue about the tcpd dependency too,
 currently most packages rely on netbase pulling it. I see arguments for
 both having the inetd depend on it if needed (some directly use libwrap)
 and having the server packages depend on it if needed (some do not
 actually use it). I favour the first option, BTW.

Yes we could do that at the same time. And I prefer the first option
as well.

regards,
guillem


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



Re: inet-superserver virtual package

2006-08-30 Thread Marco d'Itri
On Aug 30, Guillem Jover [EMAIL PROTECTED] wrote:

 I'm not convinced that duplicating update-inetd in most of the
 inetd providing packages is a good idea, even if this would allow
 xinetd to be able to replace a normal inetd easily. I'd prefer that the
 odd cases override update-inetd, via a custom script that gets called
 if present from u-i or replace it or whatever.
I can't see why this would be better.

 Also in case the mythical rewrite happens it will be easier to
 coordinate just one instance than all of them, or to sync them if
 people start fixing their instances.
I do not believe this. xinetd and rlinetd need their own versions of
the program anyway, so at best it could be shared by openbsd-inetd and
inetutils-inetd. Coordinating the changes in a 13 KB code base among
2 or 4 maintainers is easy.

  netbase then will temporarily depend on inet-superserver to allow smooth
  upgrades until the other packages will switch to a dependency on the
  virtual package[1][2].
 Do you mean only a depedency to the virtual package, w/o a real one?
No.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Why does Ubuntu have all the ideas?

2006-08-30 Thread Michelle Konzack
Am 2006-08-24 17:51:55, schrieb Rudy Godoy:

 I do believe it's more a matter of relations with press and media than
 budget. We have no easy-way-to-get-it to tell people why they would want to
 use Debian. Ubuntu, on the other hand, has achieved to do so, and what they
 tell that we can't? nothing. All what they advertise we do offer. But we
 are not good on advertise our OS.

What do we do, if one day to another 10 million or more peoples want to
use Linux (it does not mater which distribution)  ARE WE PREPARED?

I asume, the worldwide Linux resources would crash.

 We need to tell people: Debian is fine for you because it allows you to
 get your work done and be productive, whether you are an artist,
 corporate employee, student, doctor, etc.

Right...

 That kind of advertisement, focusing on things that matter for people
 more than specs and technical details, which are only interesting for
 those who already in the computing area.
 I know there is a subproject working on such things, which is great.

debian-desktop ?
debian-edu ?  (Skolelinux)

 No, I still believe we need more people and relations with press, and
 not only the technical ones, we should advertise more our work and
 good experiences like donzka, LinEx, and the others. Not only tell
 ourselves: we know we are doing things better. We should tell it to
 others too!

Hmmm...

Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


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



Re: Why does Ubuntu have all the ideas?

2006-08-30 Thread Michelle Konzack
Am 2006-08-25 11:46:20, schrieb Mgr. Peter Tuharsky:
 1b, If things don't work, it's sometimes hard to get them working 
 either. Example: Bug 372719. The OOo 2.0 keeps crashing for 2 months 
 thank to KNOWN bug in security upgrade. Now tell somebody, that Debian 

But OOo 2.0 is not in Stable!

 1c, Other cases are when something CAN be done in Debian, and even 
 documentation exists, but it is quite complicated and time consuming, 
 and truly should be much easier. Mostly the installer's playground to 
 make life easier and set up things. For example, to automatically 
 install national fonts and translation packages if the user already 
 entered his location and national data.

Right, this is one thing I mis in the installation of X.

Same for the console font since it does not fit my needs
for [EMAIL PROTECTED] or [EMAIL PROTECTED].

Using UTF-8 on the console is a nightmare...

LatArCyrHeb is no solution since it is not complete.

Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


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



Re: Why does Ubuntu have all the ideas?

2006-08-30 Thread Michelle Konzack
Am 2006-08-26 02:56:25, schrieb Hendrik Sattler:
 Am Freitag 25 August 2006 12:54 schrieb Wouter Verhelst:
  Given that a kernel image these days takes up about 50M already
 
 I guess that those that care for the smallest possible base system (and those 
 that hate initrd/initramfs) have their own kernel. My one (for a laptop) has 
 an installed size of 7456 KB (not even close to 50MB).

For Linux its true.  I have arround the same size.

 HS

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


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



Re: Why does Ubuntu have all the ideas?

2006-08-30 Thread Michelle Konzack
Am 2006-08-26 02:01:21, schrieb Benjamin Seidenberg:

 You can always use a Transnational Republic ID card.

:-)

Where can I get this?  -  Martin?

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


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



Re: Why does Ubuntu have all the ideas?

2006-08-30 Thread Michelle Konzack
Am 2006-08-27 01:19:23, schrieb Adam Borowski:

 I am pretty sure Michelle has at least _some_ sort of ID, even as an
 illegal alien.  And with the current anti-Arab scare she would be
 already deported were she lacking complete valid papers -- you can
 sit in peace if you don't travel anywhere, but by browsing
 debian-devel I get the impression Michelle travels around a lot.


If you are working for the French Ministry of Defense in conjunction
with the Interneational Court of Justice (Den Haag) you will have
some privilegues.

And yes, I can can do voyagues in Iran, Syria, Lebanon and Turkey
without any problems using a Syrien passport NON-VALID in Europe.

But thats not a problem with the MOF but with the regional Prefecture.

 Michelle, you're not a nobody.  Many people know you.  If I walked

I know and my E-mail searched in Googls for at least the last 8 Years
(This is WHY I accept several 1000' apamss per day and using
spamassassin, etc.)

 Also, the name means little.  I don't really care if an upload was
 done by a person who claims to be named Benjamin Seidenberg, I care

Since I am Hermaphrodite (I have a legal judgement for the name change)
there is a problem with my nams now...  5 diffent names...

1)  My Birthname= Tamay Dogan  (female)

2)  My illegal Adoptivname  = Carsten Konzack  (male)

3)  At the french Foreignt Legion   = Michel Clairmont (male)
and later (now women at the FL) = Michelle Clairmont   (female)

4)  And my Civil European Name  = Michelle Konzack (female)

5)  And since my friends in Morocco = Samira Samir (female + male)
know I am hermaprodite, they call me 

Now I am waiting for the European Court of jusice to decide what to do.
(I am genetic hermaphrodit, so NO doctor can tell I am female or male)

(I like to be HOW I AM - an Hermaphrodite doing its job)

Thanks, Greetings and nice Day, - confusing the World
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Toni Mueller


Hello,

On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri [EMAIL PROTECTED] wrote:
 On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote:
  Debian must decide whether it wants to ship BLOBs with licensing which
  technically does not permit redistribution.  At least 53 blobs have this
  problem.  Many of them are licensed under the GPL, but without source code
  provided.  Since the GPL only grants permission to distribute if you
  provide source code, the GPL grants no permission to distribute in these
  cases.
 Many people disagree with this interpretation.

I'm not a lawyer, but my take on this is that if someone ships you a
BLOB under the GPL, you have the legal right to demand sources from
him. So, in other words, I think Debian (or SPI? or FSF?) *could* make
a real hurricane in the press (and courts) by trying to wrestle source
code from said vendors. If that'd be good or bad for Debian, I don't
know, but it will be very expensive and time consuming.


Best,
--Toni++


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Arjan Oosting
Op wo, 30-08-2006 te 17:16 +0200, schreef Toni Mueller:
 
 Hello,
 
 On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri [EMAIL PROTECTED] wrote:
  On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote:
   Debian must decide whether it wants to ship BLOBs with licensing which
   technically does not permit redistribution.  At least 53 blobs have this
   problem.  Many of them are licensed under the GPL, but without source code
   provided.  Since the GPL only grants permission to distribute if you
   provide source code, the GPL grants no permission to distribute in these
   cases.
  Many people disagree with this interpretation.
 
 I'm not a lawyer, but my take on this is that if someone ships you a
 BLOB under the GPL, you have the legal right to demand sources from
 him. So, in other words, I think Debian (or SPI? or FSF?) *could* make
 a real hurricane in the press (and courts) by trying to wrestle source
 code from said vendors. If that'd be good or bad for Debian, I don't
 know, but it will be very expensive and time consuming.

No you can not demand this from the vendor which owns the copyright on
the BLOB. They are not bound by the GPL and can distribute the BLOB
anyway the want. 

Third parties, like Debian, are bound by the GPL to distribute the BLOB
with the corresponding sources and if they don't distribute the source
the can not distribute the BLOB. 

Of course IANAL and don't know the fine details of copyright law.

Greetings Arjan


signature.asc
Description: Dit berichtdeel is digitaal ondertekend


Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Sven Luther
On Wed, Aug 30, 2006 at 05:16:29PM +0200, Toni Mueller wrote:
 
 
 Hello,
 
 On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri [EMAIL PROTECTED] wrote:
  On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote:
   Debian must decide whether it wants to ship BLOBs with licensing which
   technically does not permit redistribution.  At least 53 blobs have this
   problem.  Many of them are licensed under the GPL, but without source code
   provided.  Since the GPL only grants permission to distribute if you
   provide source code, the GPL grants no permission to distribute in these
   cases.
  Many people disagree with this interpretation.
 
 I'm not a lawyer, but my take on this is that if someone ships you a
 BLOB under the GPL, you have the legal right to demand sources from
 him. So, in other words, I think Debian (or SPI? or FSF?) *could* make
 a real hurricane in the press (and courts) by trying to wrestle source
 code from said vendors. If that'd be good or bad for Debian, I don't
 know, but it will be very expensive and time consuming.

My own understanding, and we discussed this on -legal when we aproached
broadcom about the tg3 licencing, is that this is not the case, not really
anyway.

What happens, is that we, debian have not the possibility to provide those
sources, and as thus, simply lose all rights per the GPL to distribute the
source code in question, and thus what could happen, would be for the
copyright holder to sue us for not respecting the GPL clauses. Obviously,
since he doesn't do so himself, he would lose anyway, so the point is mostly
moot, but the GPL itself says it doesn't allow us to distribute the
problematic code in those cases.

Since the firmware blobs are not derivative works of the kernel, but
constitute mere agregation in the same binary format, the authors of other
pieces of GPLed code fo the linux kernel cannot even sue us for distributing
the kernel code with those GPL-violating binary BLOBs.

Friendly,

Sven Luther


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



Re: Update: status of inetd

2006-08-30 Thread Jean-Christophe Dubacq
On Mon, Aug 28, 2006 at 12:58:27PM +0200, Marco d'Itri wrote:
 On Aug 28, Roger Leigh [EMAIL PROTECTED] wrote:
 
  1) Split out update-inetd from netbase into a new inetd package.
 No, because e.g. xinetd needs a totally different update-inetd program.
 It's simpler if each inetd package will ship its own update-inetd.


If I understood correctly, all the update-inetd scripts have to provide
for each and every inetd superserver, or at least fill in a list of
calls to update-inetd. Why?

- Install openbsd-inetd
- Install inetd-using server A
- replace openbsd-inetd by xinetd
- server A was never registered by xinetd !

Instead, all packages should call a common update-inetd minus the last
line. This common part registers the arguments for the service under a
common format. Then it calls a inetd-specific script that parses those
informations, and puts those in the correct form (files in
/etc/xinetd.d/, big file in /etc/inetd.conf,...). In the postinst of
every inetd superserver, this specific script is also called. In the
prerm of the superserver, the inetd-specific files are deleted.

I do not see how one can do otherwise, unless every inetd superserver is
capable of migrating data from any other superserver.


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



Re: Update: status of inetd

2006-08-30 Thread Marco d'Itri
On Aug 30, Jean-Christophe Dubacq [EMAIL PROTECTED] wrote:

 Instead, all packages should call a common update-inetd minus the last
 line. This common part registers the arguments for the service under a
 common format. Then it calls a inetd-specific script that parses those
We do not have a new, improved update-inetd.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


ITP: adun.app -- a Molecular Simulator

2006-08-30 Thread Gürkan Sengün

Package: wnpp
Severity: wishlist

* Package name: adun.app
 Version : 0.5
 Upstream Authors : Michael A. Johnston,
I. F. Galván,
Jordi Villà-Freixa
* URL : http://diana.imim.es/Adun
* License : GNU GPL
 Description : Molecular Simulator
 Adun is a new extendible molecular simulation program that also includes data 
management and analysis capabilities.

.
Homepage: http://diana.imim.es/Adun


-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc
Locale: LANG=POSIX, LC_CTYPE=POSIX


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Joe Smith


Sven Luther [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]

On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote:

On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote:

 Debian must decide whether it wants to ship BLOBs with licensing which
 technically does not permit redistribution.  At least 53 blobs have 
 this
 problem.  Many of them are licensed under the GPL, but without source 
 code

 provided.  Since the GPL only grants permission to distribute if you
 provide source code, the GPL grants no permission to distribute in 
 these

 cases.
Many people disagree with this interpretation.


A few very vocal people do. I guess they can be counted on the fingers of 
both

hands or so.



I think everybody can agree that it would be clearer if the blobs used a 
licence that clearly allows distribution without requiring source.


In the case of the GPL that is definately not clear.


About the main issue:
As I see it, there are three possible catagories for drivers using firmware 
that all drivers should ideally fall into assuming the driver  part is free 
:


1. Module and firmware in free. (The firmware can be compiled into the 
module, or can be loaded from a file.)


2. Module in free, firmware in nonfree, loaded from file by driver. [One 
could argue that the modules belong ion contrib, unless the firmware is

optional (perhaps allowing access to non-essential features)].

3. Module in non-free. [Firmware compiled into module, has not yet be 
seperated into seperate file. This is acceptable, but many of these could be 
converted to type 2 if somebody puts in the work].



I know we have some modules of type 1. I'm pretty sure we have some modules 
of type 3. It has not been clear to me if we currently have any modules of 
type 2.

Obviously if the infrastucture is not there, that should be fixed.

Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 
modules. This can definately be fixed, but doing it for etch could delay 
release.


Besides all of that we have quite a few modules with problematic licences. 
Generally the licence problem is on the firmware, although some might affect 
the
rest of the driver. Some are type-3 style (firmware hard-coded into module, 
firmware lacking source.)Many of those could be shipped as type-3 modules if 
licence clarification can be obtained (or preferable: relicencing). A few 
are type-2 style, they could be shipped as type-2 if proper clarification 
can be obtained.



The above is a rough summer of the problems as I understand it. Please 
correct be if I am wrong.



So the question I have is how long would etch need to be delayed to add 
support for non-free firmware to D-I?




We could also push back the freeze on the kernel by the same amount and have 
some people work on obtaining clarification on some of the problematic 
licences.


With the combination of those two we could end up with having very few 
drivers not ship, and all shipped drivers both free and non-free be usable 
during installation.


While pushing Etch back is a big deal, it almost seems to me that some of 
the proposed GRs are an even bigger deal, and, as has been pointed out, the 
GRs would probably only make a difference for a small number of modules, 
unless we ignore the problematic licencing of most of the remaining drivers.





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



Bug#385349: ITP: bazaar-webserve -- allow a bzr branch to be accessed via the web

2006-08-30 Thread James Westby
Package: wnpp
Severity: wishlist
Owner: James Westby [EMAIL PROTECTED]

* Package name: bazaar-webserve
  Version : Unknown
  Upstream Author : Goffredo Baroncelli kreijack AT inwind DOT it
* URL : http://goffredo-baroncelli.homelinux.net/bazaar-dev/
* License : GPL
  Programming Lang: Python
  Description : allow a bzr branch to be accessed via the Web

  bazaar-webserve provides both a plugin to bzr, and set of cgi scripts
  that allow a bzr branch to be accessed over the Web. It is similar in
  intent to websvn and gitweb. 
  .
  It first provides a command (webserve) to bzr which starts up a
  server and receives HTTP requests. It can also work via CGI and so use
  a HTTP server to handle the requests.
  .
  It allows for browsing of the repository, and for browsing through
  revisions and viewing diffs between revisions. It can also be
  configured to provide a .tar.gz download of a requested revision, and
  to allow branching from the hosted branch.
  .
   Homepage: http://goffredo-baroncelli.homelinux.net/bazaar-dev/


The upstream name of this software is bazaar-webserve, so I am going
with that, but bzr-webserve would fit in better with the rest of the
debian bzr naming scheme. 

I have put version unknown as there have not been any releases as such.
I am going to contact the author and ask whether he will be making
releases. If he isn't then I will package appropriately named snapshots.

James

-- 
  James Westby   --GPG Key ID: B577FE13-- http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256



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



Re: Bug#385338: wish: dpkg-reconfigure localepurge to select when to run localepurge automatically

2006-08-30 Thread Paul Seelig
CC'ed debian-devel

On Wed, Aug 30, 2006 at 04:49:11PM +0100, João Batista wrote:
 
 I'd like to propose a facility, configurable when running
 dpkg-reconfigure localepurge , to allow the sysadmin to select when
 localepurge should be run e.g.: 
   - everytime dpkg/apt is run (default)
   - manually
 
Sorry, but i won't inlude this. It surely sounds like a good idea and all,
but all this user friendly configuration facilities are starting to become
more than a nuisance for me.

It has started to take more time and thought than the main functionality i
was primarily interested in. My personal goal with this program has since
long been reached and i really don't want to bother about extending it
anymore. Actually i was already thinking about ripping out all the debconf
facilities and going back to plain old fashioned manual configuration via
plain text configuration file. But i can imagine the outcry of the user
base, which seems to have grown pretty large by now.

Maybe it's time to simply give up on it so that someone else with more time
and ambition might want to maintain it for Debian. Any takers?


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



Deploying configuration as packages

2006-08-30 Thread Josselin Mouette
Hi list,

For deploying a number of servers at a client's, we've started using
package-based configuration.  The idea is not new and not complicated:
put the local configuration files in Debian packages to deploy them.

This answers to the following needs:
  * simplicity;
  * ability to deploy only some of the configuration or to generate
the configuration depending on the server;
  * differentiating modifications made by the local administrator
from those coming from the deployment tool (as dpkg asks in this
case).

Other options that come to mind are cfengine, but it is too complex for
small or medium-sized installations, or a RCS, but it isn't flexible
enough.

However not all Debian packages allow such things easily.  Packages that
split their configuration files, like apache or exim4, allow to ship
extra configuration files. Some others allow multiple layers of
defaults; for example, one of the reasons for the GConf changes was to
allow such packages to be deployed.  For other packages, the
configuration shipped by Debian has to be replaced.

Several options were considered:
 1. Customize the configuration files in every Debian package we
want to have configured.  This works as expected, but it means a
lot of work whenever the packages are updated, e.g. for security
updates.
 2. Ship the packages as provided by Debian, and replace the
configuration files by maintainer scripts in specific packages.
This is ugly, and leads to dpkg asking whether files should be
overwritten when it shouldn't.
 3. Strip the packages from their configuration files, and ship the
configuration files in specific packages.  As the stripping
operation can be automated, this is acceptable in production.
Option 3 is currently winning, but we'd like to improve things in the
future.

First question to the developers, what are you using for deploying
configuration on your servers?

For something more interesting to debian-devel contributors, what could
be done to improve the situation?
  * The first thing that comes to mind is the ability to divert
conffiles. This could help a lot to build things around existing
packages. Do you think this is realistic? Can this be done with
the current conffile architecture in dpkg?
  * Otherwise, there could be an interface to dpkg for handling
special cases, putting conffiles in a different internal state
with a specific command.
  * ... any other ideas are welcome.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée


Re: Deploying configuration as packages

2006-08-30 Thread martin f krafft
also sprach Josselin Mouette [EMAIL PROTECTED] [2006.08.30.2023 +0200]:
 First question to the developers, what are you using for deploying
 configuration on your servers?

cfengine and puppet

   * The first thing that comes to mind is the ability to divert
 conffiles. This could help a lot to build things around existing
 packages. Do you think this is realistic? Can this be done with
 the current conffile architecture in dpkg?

no, you will lose data if you try. Arguably this should be fixed.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
a warm bed in a house sounds a mite better
 than eating a hot dog on a stick
 with an old geezer traveling on a lawn mower.
-- alvin straight (the straight story)


signature.asc
Description: Digital signature (GPG/PGP)


Re: Bug#385338: wish: dpkg-reconfigure localepurge to select when to run localepurge automatically

2006-08-30 Thread Steve Greenland
On 30-Aug-06, 12:38 (CDT), Paul Seelig [EMAIL PROTECTED] wrote: 
 CC'ed debian-devel
 
 On Wed, Aug 30, 2006 at 04:49:11PM +0100, Jo?o Batista wrote:
  
  I'd like to propose a facility, configurable when running
  dpkg-reconfigure localepurge , to allow the sysadmin to select when
  localepurge should be run e.g.: 
- everytime dpkg/apt is run (default)
- manually
  
 Sorry, but i won't inlude this. It surely sounds like a good idea and all,
 but all this user friendly configuration facilities are starting to become
 more than a nuisance for me.

And the desired functionality is easily achieved by removing
/etc/apt/apt.conf.d/99-localepurge, right? Debconf is an appriate tool
when there is no obvious correct answer, but for these 1% options,
editing the config file is no burden.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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



Re: Deploying configuration as packages

2006-08-30 Thread Eric Dorland
* martin f krafft ([EMAIL PROTECTED]) wrote:
 also sprach Josselin Mouette [EMAIL PROTECTED] [2006.08.30.2023 +0200]:
  First question to the developers, what are you using for deploying
  configuration on your servers?
 
 cfengine and puppet

Are you using both at the same time? Or moving from one to the other? 
 
* The first thing that comes to mind is the ability to divert
  conffiles. This could help a lot to build things around existing
  packages. Do you think this is realistic? Can this be done with
  the current conffile architecture in dpkg?
 
 no, you will lose data if you try. Arguably this should be fixed.
 



-- 
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6



signature.asc
Description: Digital signature


Re: bug rates

2006-08-30 Thread Goswin von Brederlow
Joey Hess [EMAIL PROTECTED] writes:

 I wonder if it would be worthwhile to try to quantify this some more,
 by looking at all the RC bugs over a period of time and determining:

 a. What percentage were caused by issues in new uploads.
 b. What percentage by transitions.
 c. What percentage also affect stable.

 and finding the relative time-to-fix of each of these.

d. How many RC bugs are there in stable.
e. How many RC bugs from stable are fixed in etch.

 -- 
 see shy jo

As a start a thrid line in the RC bug plot for stable bugs might be
nice. Just to see how fast RC bugs get discovered post release.

MfG
Goswin


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



Re: Debian ISOs

2006-08-30 Thread Bruce Sass
On Wed August 30 2006 02:52, Subredu Manuel wrote:
 Josselin Mouette wrote:
  Le jeudi 17 août 2006 à 11:48 -0400, Anthony L. Bryan a écrit :
 
  Given that downloads like Debian ISOs are already putting a heavy
  bandwidth load on the servers and that they are already shared
  among many servers, I don't think it is a good idea to encourage
  users to load several servers at once with one download. We should
  instead push bittorrent as the main distribution media for ISOs.

  I don't think you got the picture. Metalink can contain information
 for download using the following protocols:
  *) http
  *) ftp
  *) bittorrent
  *) e2k
...

You seem to be ignoring that metalinker will use multiple protocols, 
servers, and connections in an effort to get the fastest download. 
http://www.metalinker.org/Metalink_3.0_Spec.pdf also indicates it will 
switch servers if the download rate falls, and perhaps even perpetuate 
old torrents --- which is all great for the client, but will pretty 
much guarantee worse than possible performance from the servers.

It is also not clear what will happen when a release is made and 
hundreds (thousands?) of clients hit the fastest mirror, whose download 
rate then drops, prompting all the clients to try switching to the new 
fastest mirror, whose rate then drops, ...  At the very least there 
will be more overhead traffic for the servers, worst case could be some 
kind of nasty cyclic oscillations with the server loads which 
undermines transfer efficiency for everyone.  Ya, that's kinda FUDish, 
but given the newness and limited deployment of the technology, 
speculation is about all we have to work with.

The objective is to ease and spread out the load on the servers; 
bittorrent and socially engineered access to the less efficient 
protocols is more likely to do that than bittorrent + ftp + http + 
multiple servers/client. IMO

I think Metalinks are an interesting idea which deserve investigation, 
but it seems clear they would result in more server overhead and 
unclear whether the load spreading would offset that or even happen[1].


- Bruce

[1] could clients be attracted to a few fast ftp servers and the often 
slow-to-start torrents end up being underutilized... the exact opposite 
of what is best for Debian's servers.



Use of dpkg --set-selections is brain-dead?

2006-08-30 Thread Michael S. Peek

Hello gurus,

I thought I would be slick and write a package that contains a script 
that will figure out what should be installed/removed/upgraded/etc. on 
each of the machines where I work.  (Using sarge, btw.)  I had planned 
to do this by listing each of the packages and it's install status in a 
file, then piping that file to 'dpkg --set-selections', and then using 
'apt-get dselect-upgrade' to process the new package selections.


Unfortunately, this doesn't seem to work as I expected.

I've traced my problem down to the use of 'dpkg --set-selections' 
command.  As an example, I have a package named tiem-nis-client-cfg that 
sets up NIS for generic workstations.  If I understand correctly, I 
should be able to do the following:


   echo tiem-nis-client-cfg  install | dpkg --set-selections

And then, when I type 'dpkg --get-selections', I should see 
tiem-nis-client-cfg   install one some line in the output.  
Unfortunately, this doesn't seem to work:


   ~# echo tiem-nis-client-cfg  install | dpkg --set-selections ; 
echo $? ; dpkg --get-selections | grep 'tiem-nis-client-cfg' ; echo $?

   0
   1

The dpkg --set-selections command prints no error, and returns no error 
code, but tiem-nis-client-cfg isn't set for installation.


I know that the package database knows about my tiem-nis-client-cfg, 
because I can do this:


   ~# apt-cache show tiem-nis-client-cfg
   Package: tiem-nis-client-cfg
   ...blah, blah, blah...

And I can install the package by hand:

   ~# apt-get install tiem-nis-client-cfg
   Reading Package Lists... Done
   Building Dependency Tree... Done
   The following extra packages will be installed:
 libslp1 nis
   Suggested packages:
 slpd openslp-doc
   The following NEW packages will be installed:
 libslp1 nis tiem-nis-client-cfg
   0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
   Need to get 291kB of archives.
   After unpacking 1065kB of additional disk space will be used.
   Do you want to continue? [Y/n]
   Get:1 http://ftp.us.debian.org sarge/main libslp1 1.0.11a-2 [47.3kB]
   Get:2 http://tortoise sarge/non-free tiem-nis-client-cfg 1.4 [3780B]
   Get:3 http://ftp.us.debian.org sarge/main nis 3.13-2 [240kB]   
   Fetched 291kB in 0s (293kB/s)

   Preconfiguring packages ...
   Selecting previously deselected package libslp1.
   (Reading database ... 50195 files and directories currently installed.)
   Unpacking libslp1 (from .../libslp1_1.0.11a-2_i386.deb) ...
   Selecting previously deselected package nis.
   Unpacking nis (from .../archives/nis_3.13-2_i386.deb) ...
   Setting up libslp1 (1.0.11a-2) ...
  
   Setting up nis (3.13-2) ...

   Setting NIS domainname to: tiem.utk.edu
   Starting NIS services: ypbind [binding to YP server .. 
backgrounded]
  
   (Reading database ... 50289 files and directories currently installed.)
   Unpacking tiem-nis-client-cfg (from 
.../tiem-nis-client-cfg_1.4_all.deb) ...

   Setting up tiem-nis-client-cfg (1.4) ...
   Setting NIS domainname to: tiem
   Starting NIS services: ypbind


Tell me, oh wise gurus of Debian -- is dpkg just brain-dead?  Is the man 
page horribly wrong/out-of-date?  Or what?


Confused,

Michael Peek


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Nathanael Nerode
Joe Smith wrote:

 Sven Luther [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
 On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote:
 On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote:

  Debian must decide whether it wants to ship BLOBs with licensing which
  technically does not permit redistribution.  At least 53 blobs have
  this
  problem.  Many of them are licensed under the GPL, but without source
  code
  provided.  Since the GPL only grants permission to distribute if you
  provide source code, the GPL grants no permission to distribute in
  these
  cases.
 Many people disagree with this interpretation.

 A few very vocal people do. I guess they can be counted on the fingers of
 both
 hands or so.

Probably less.  The people who disagree with this interpretation are
contradicting the plain text of the GPL, ignoring copyright law, ignoring
the stated intent of the drafters of the GPL and the FSF, etc.

As I said, the distributors of this unlicensed material probably *intended*
to give it a proper distribution license.  Should Debian rely on the
assumption of good intentions?  Debian doesn't do that for copyright issues
in *general*.

 I think everybody can agree that it would be clearer if the blobs used a
 licence that clearly allows distribution without requiring source.
 
 In the case of the GPL that is definately not clear.
 
 
 About the main issue:
 As I see it, there are three possible catagories for drivers using
 firmware
 that all drivers should ideally fall into assuming the driver  part is
 free
 :
 
 1. Module and firmware in free. (The firmware can be compiled into the
 module, or can be loaded from a file.)
 
 2. Module in free, firmware in nonfree, loaded from file by driver. [One
 could argue that the modules belong ion contrib, unless the firmware is
 optional (perhaps allowing access to non-essential features)].
 
 3. Module in non-free. [Firmware compiled into module, has not yet be
 seperated into seperate file. This is acceptable, but many of these could
 be converted to type 2 if somebody puts in the work].
 
 
 I know we have some modules of type 1. I'm pretty sure we have some
 modules of type 3. It has not been clear to me if we currently have any
 modules of type 2.

Yes, we do. bluez-firmware and atmel-firmware.

 Obviously if the infrastucture is not there, that should be fixed.

It's there except for d-i.

 Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3
 modules. This can definately be fixed, but doing it for etch could delay
 release.

Right.

 Besides all of that we have quite a few modules with problematic licences.
 Generally the licence problem is on the firmware, although some might
 affect the
 rest of the driver. Some are type-3 style (firmware hard-coded into
 module, firmware lacking source.)Many of those could be shipped as type-3
 modules if licence clarification can be obtained (or preferable:
 relicencing). A few are type-2 style, they could be shipped as type-2 if
 proper clarification can be obtained.
 
 
 The above is a rough summer of the problems as I understand it. Please
 correct be if I am wrong.

That's all correct.

 So the question I have is how long would etch need to be delayed to add
 support for non-free firmware to D-I?

Joey Hess estimated 6 months work, but that was to implement a whole bunch
of uncommon special cases.  I think it is totally unnecessary to implement
all, or even any, of those.

http://lists.debian.org/debian-vote/2006/08/msg00122.html

For (2) from that post, which is the key sticking point for d-i, it needs to
be done anyway, and honestly should not take more than a month if someone
bothers.

So -- point me to the correct parts of the installer.  I don't know where to
find this anna. libdebian-installer I'm looking at -- it would be a great
help if someone could direct me to the part of the code which loads udebs
from disk/network, because I can't find it.  Is that all in 'anna', which I
can't find?  :-/  If I can't find the source code for 'anna', I can't fix
it.

(3) is trivial and simply requires the will to fix RC bugs.

(4) is frankly not nearly as important as Joey makes it out to be.  It is
very unlikely that someone will have a machine where *both* the CD *and*
the NIC *and* the floppy drive if present *and* the USB driver (USB key)
need non-free firmware.  

As long as there is one piece of hardware with fully free drivers which can
be used to load the additional non-free material on the machine, it is
perfectly tolerable that an alternate piece of hardware is not so
supported.  (I've seen systems where the NIC needed non-free firmware
downloaded and ones where the CD did, but never ones where both did.)  I
know it's theoretically possible that someone will buy a hell machine
where every single peripheral requires a non-free firmware download -- but
it's unlikely.  And if that happens, they can still use the hard drive
method or master their own CD.

 We could also 

Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Nathanael Nerode
Sven Luther wrote:

 Since the firmware blobs are not derivative works of the kernel, but
 constitute mere agregation in the same binary format, the authors of other
 pieces of GPLed code fo the linux kernel cannot even sue us for
 distributing the kernel code with those GPL-violating binary BLOBs.

This is not clear in the cases where the blobs are embedded directly into
the kernel, particularly when they're embedded in the same source files. 
There's a case to be made that this is *not* mere aggregation, but creation
of an enhanced combination work which is derivative of both the firmware
and the other parts of the kernel.  Simply putting files side by side is
mere aggregation -- what's happening with the drivers and firmware might be
mere aggregation, but nobody can be sure until a court case happens.

-- 
Nathanael Nerode  [EMAIL PROTECTED]

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Nathanael Nerode
Steve Langasek wrote:

 On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote:
 
 Debian needs to make a decision on how it will deal with this legal
 minefield.  That is higher priority than the entire discussion going on
 right now, because it determines whether Debian will distribute these 53
 BLOBs *at all*, in 'main' or in 'non-free'.
 
 Oddly enough nobody has proposed a GR addressing this,
 
 Because voting is an absurd means of settling questions of legal
 liability. It's the domain of the ftp team to determine whether we can
 legally distribute a package on our mirrors.

Actually, letting an overworked team of four with (to my knowledge) zero
legal expertise settle questions of legal liability is pretty absurd too. 
I know this is Debian tradition, but it's worth thinking about whether it
really makes sense.

Debian-legal has very little legal expertise, and as a result the consensus
errs on the side of caution at essentially all times with regard to
copyright.  Probably too much caution, but without getting an actual legal
opinion, that seems like the right thing to do.  Should the ftpmasters, who
have even less legal expertise, ever take the risk of erring on the side of
recklessness?  (This risk is currently being taken with the
mislicensed 'firmware' BLOBs.)  Does this expose anyone but the ftp team to
legal liability?

Now, if the rest of Debian has repeatedly disavowed all responsibility, it
may be that the ftp team and only the ftp team are *personally* liable if
Debian makes an illegal distribution, and in that case it would make sense
for them to determine such things.  I'm not sure the ftpmasters are
actually comfortatble with assuming personal legal liability for every
package in Debian though.  I wouldn't be!

-- 
Nathanael Nerode  [EMAIL PROTECTED]

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Sven Luther
On Wed, Aug 30, 2006 at 08:18:28PM -0400, Nathanael Nerode wrote:
 Sven Luther wrote:
 
  Since the firmware blobs are not derivative works of the kernel, but
  constitute mere agregation in the same binary format, the authors of other
  pieces of GPLed code fo the linux kernel cannot even sue us for
  distributing the kernel code with those GPL-violating binary BLOBs.
 
 This is not clear in the cases where the blobs are embedded directly into

Please reread the discussion on debian-legal about this, where consensus was
mostly found to support this idea, and also remember that we contacted
broadcom with this analysis, who contacted their legal team, and i also mailed
the FSF lawyers with it, and got no counter-claim to it.

 the kernel, particularly when they're embedded in the same source files. 
 There's a case to be made that this is *not* mere aggregation, but creation
 of an enhanced combination work which is derivative of both the firmware
 and the other parts of the kernel.  Simply putting files side by side is
 mere aggregation -- what's happening with the drivers and firmware might be
 mere aggregation, but nobody can be sure until a court case happens.

Well, in the debian-legal discussion i gave plenty of counter examples,
ranging from a firmware flasher (little C program with embedded firmware,
exact same case as the kernel situation), to compressed binaries with
uncompressing software embedded, passing by filesystem binaries containing
both GPLed content as well as non-free content.

So, all in all, unless you bring new evidence, there is really very little
doubt about this, unless you want to consider your hardware a derived work of
the linux kernel, but i doubt a judge will follow you on this one.

IANAL, but there is a part of common sense and simple logic in most legal
cases.

Friendly,

Sven Luther


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



Re: Deploying configuration as packages

2006-08-30 Thread Josselin Mouette
Le mercredi 30 août 2006 à 21:26 +0200, martin f krafft a écrit :
* The first thing that comes to mind is the ability to divert
  conffiles. This could help a lot to build things around existing
  packages. Do you think this is realistic? Can this be done with
  the current conffile architecture in dpkg?
 
 no, you will lose data if you try. Arguably this should be fixed.

Sure. The question is whether it is realistic to fix dpkg in this
matter.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée


Re: ITP: adun.app -- a Molecular Simulator

2006-08-30 Thread Steffen Joeris
Hi

On Thursday 31 August 2006 01:58, Gürkan Sengün wrote:
 Package: wnpp
 Severity: wishlist

 * Package name: adun.app
Maybe I miss some essential parts, but I always wonder why some people add 
a .app to the software name? Can you please give me a short explanation or 
point me to a previous thread?

Cheers
Steffen


pgpxBWvNnr2RF.pgp
Description: PGP signature


Re: ITP: adun.app -- a Molecular Simulator

2006-08-30 Thread Daniel Dickinson
On Thu, Aug 31, 2006 at 09:24:21PM +1000, Steffen Joeris wrote:
 Hi
 
  * Package name: adun.app
 Maybe I miss some essential parts, but I always wonder why some people add 
 a .app to the software name? Can you please give me a short explanation or 
 point me to a previous thread?
 

IIRC .app is usually used by apps with gnustep support (e.g. WindowMaker
dockapps). It doesn't normally mean they only work on gnustep though,
just that they use some features from gnustep, when available.


-- 
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C  http://gnupg.org
And that's my crabbing done for the day.  Got it out of the way early, 
now I have the rest of the afternoon to sniff fragrant tea-roses or 
strangle cute bunnies or something.   -- Michael Devore


signature.asc
Description: Digital signature


Re: inet-superserver virtual package

2006-08-30 Thread Guillem Jover
On Wed, 2006-08-30 at 14:22:07 +0200, Marco d'Itri wrote:
 On Aug 30, Guillem Jover wrote:
  I'm not convinced that duplicating update-inetd in most of the
  inetd providing packages is a good idea, even if this would allow
  xinetd to be able to replace a normal inetd easily. I'd prefer that the
  odd cases override update-inetd, via a custom script that gets called
  if present from u-i or replace it or whatever.

 I can't see why this would be better.

Well, if we want to be able to replace any of the inetd with any other
one we need a neutral format (as someone else also said in the other
thread), this neutral format could be the existing inetd.conf, because
the other packages should support already converting from it, so the
only thing needed would be to add this hook support to update-inetd for
the specific cases where the application does not read the neutral
format directly. Also because this hook support should imply minimal
code, just passing the whole arguments to it if the file is present.

  Also in case the mythical rewrite happens it will be easier to
  coordinate just one instance than all of them, or to sync them if
  people start fixing their instances.

 I do not believe this. xinetd and rlinetd need their own versions of
 the program anyway, so at best it could be shared by openbsd-inetd and
 inetutils-inetd. Coordinating the changes in a 13 KB code base among
 2 or 4 maintainers is easy.

This is a fair point, thought there would be way more of those. But
consider the above, and if the others have to support the neutral
format, we may as well share the code, for all of them.

   netbase then will temporarily depend on inet-superserver to allow smooth
   upgrades until the other packages will switch to a dependency on the
   virtual package[1][2].

  Do you mean only a depedency to the virtual package, w/o a real one?

 No.

Then I agree here with Roger, that spreading this dependency all over
the place makes future changes difficult innecessarily, even if you
can consider me biased I'd think the same if the package for this
depedency was going to be inetutils-inetd. ;)

regards,
guillem


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



Re: bug rates

2006-08-30 Thread Nathanael Nerode
Joey Hess wrote:

 Steve Langasek wrote (elsewhere):
 something changes in the archive (often for a transition that needs
 to happen), a large number of packages are broken by this, and some
 appreciable number of the maintainers don't respond in a reasonable
 amount of time (reasonable defined as sufficient to make headway
 against the RC bug count; average time to bugfix  average interval
 between archive-breaking transitions).
 
 I wonder if you have any numbers on this? My gut feeling for a while has
 been that part of what's keeping the RC bug levels in balance is that
 we have a constant stream of RC bugs being filed for issues that are not
 new but have only turned up as things get tested.

Yep.

 A certian percentage 
 of these affect stable too. One obvious example is security bugs. It
 seems to me that if you look at the RC bug graph, most of the sharp
 spikes and dips are due to the kind of transitional RC bugs you're
 talking about, which says that we do pretty well at dealing with those,
 at least for significant transitions that cause a lot of similar bugs.
 
 One of my problems with our current release process is that it doesn't
 seem to take into account the bugs that exist in stable. By the current
 metrics we could easily be in a position today where testing has many
 fewer RC bugs than stable, but still be far from a release. And even if
 we get the RC bugs to zero and make a release, that release will have
 many undiscovered RC bugs which will turn up later.

Yep.

 That makes it hard 
 for me to worry about bringing the count down to zero, since it's really
 just pushing the iceberg underwater for an instant.

Yeah, I think you have a good point here.

Personally, I would prioritize RC bugs which apply to key packages
 -- the benefit from getting those RC-bug-free is
larger than that of getting other packages RC-bug-free.  Unfortunately,
some vital packages like the toolchain packages and the kernel have some of
the oldest and most irritating RC bugs.  Licensing

 I wonder if it would be worthwhile to try to quantify this some more,
 by looking at all the RC bugs over a period of time and determining:
 
 a. What percentage were caused by issues in new uploads.

Weirdly, these are often the quickest to be fixed.  Exceptions: Bugs
caused by large upstream changes; bugs in packages with inactive
or inattentive maintainers.

 b. What percentage by transitions.

Gah, probably most of them.  Time-to-fix is weird for transitions; most
packages are fixed very quickly, and then there's a long tail, primarily
caused by inactive maintainers.  Amaya's been working on finishing up
some of those long tails, as have I.  Mostly they don't get finished.

 c. What percentage also affect stable.

I try to versiontag for this.  This should be a detectable quantity now, 
thanks to versiontagging.  These, oddly (or perhaps not so oddly) are 
often the ones which take the longest to fix.  However, they're also where
I put my priorities, because long-standing bugs are substantially more
annoying than new bugs.

A release where we fixed all the (discovered and undiscovered) RC bugs from
the *previous* release would be a very successful release.  :-)

 and finding the relative time-to-fix of each of these.

-- 
Nathanael Nerode  [EMAIL PROTECTED]

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Nathanael Nerode
Toni Mueller wrote:

 
 
 Hello,
 
 On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri [EMAIL PROTECTED] wrote:
 On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote:
  Debian must decide whether it wants to ship BLOBs with licensing which
  technically does not permit redistribution.  At least 53 blobs have
  this
  problem.  Many of them are licensed under the GPL, but without source
  code
  provided.  Since the GPL only grants permission to distribute if you
  provide source code, the GPL grants no permission to distribute in
  these cases.
 Many people disagree with this interpretation.

Marco trolled again.  FYI, no serious person disagrees with this
interpretation.

From the GPL:

3. You may copy and distribute the Program (or a work based on it, 
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

   a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,

-- Debian is not doing this for the BLOBs

b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,

-- Debian is not doing this for anything

c) Accompany it with the information you received as to the offer
to distribute corresponding source code.  (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)

-- Debian is not allowed to do this

So Debian isn't satisfying the conditions of clause 3.  Therefore, the GPL
does not grant Debian permission to distribute the BLOBs in object code or
executable form.

 I'm not a lawyer, but my take on this is that if someone ships you a
 BLOB under the GPL, you have the legal right to demand sources from
 him.

Unfortunately not.  Generally, only a copyright holder can sue for GPL
violation.

(In contrast, Debian's Social Contract promises that Debian will distribute
source code for all the programs in Debian -- so under common law I could
sue Debian for false advertising because it isn't distributing source code
for some of the programs.)

*However*, consider the following case:
(1) The driver is written by person A and released properly under the GPL.
(2) The firmware is written by corporation B and distributed without source.
(3) Either B or person C combines the firmware with the driver to make a
single work, and distributes it -- without the source for the firmware.

In this case, person A can sue any distributor of the combined work. 
Arguably, any contributor with copyright in any part of the Linux kernel
might be able to sue any distributor of a kernel with firmware in it.  Some
of the contributors to the kernel are very vociferously against sourceless
firmware, and might actually do it.

Dropping -vote, setting followups to -legal.

-- 
Nathanael Nerode  [EMAIL PROTECTED]

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Steve Langasek
On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote:

  On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote:

  Debian needs to make a decision on how it will deal with this legal
  minefield.  That is higher priority than the entire discussion going on
  right now, because it determines whether Debian will distribute these 53
  BLOBs *at all*, in 'main' or in 'non-free'.

  Oddly enough nobody has proposed a GR addressing this,

  Because voting is an absurd means of settling questions of legal
  liability. It's the domain of the ftp team to determine whether we can
  legally distribute a package on our mirrors.

 Actually, letting an overworked team of four with (to my knowledge) zero
 legal expertise settle questions of legal liability is pretty absurd too. 

They are the team responsible for vetting the legality of what's distributed
on the mirrors.  None of them have any legal expertise to my knowledge; but
they do know where the lawyers are if they have questions, and they *are*
the ones in the hot seat(s).

 Should the ftpmasters, who have even less legal expertise,

Judging by some of the nonsense that debian-legal is typically riddled with,
if I were an ftpmaster I would find that claim insulting.

The only claim to expertise that debian-legal has is in the area of
analyzing license terms and how they stack up against the requirements of
the DFSG.  That is an important function, but it is *not* legal expertise.

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


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



Re: ITP: adun.app -- a Molecular Simulator

2006-08-30 Thread Hubert Chan
On Wed, 30 Aug 2006 22:12:04 -0400, Daniel Dickinson [EMAIL PROTECTED] said:

 On Thu, Aug 31, 2006 at 09:24:21PM +1000, Steffen Joeris wrote:
 Hi
 
  * Package name : adun.app
 Maybe I miss some essential parts, but I always wonder why some
 people add a .app to the software name? Can you please give me a
 short explanation or point me to a previous thread?

 IIRC .app is usually used by apps with gnustep support (e.g. WindowMaker
 dockapps). It doesn't normally mean they only work on gnustep though,
 just that they use some features from gnustep, when available.

To clarify, .app is generally used by GNUstep programs, and for some
dockapps.  Dockapps that are not written specifically for GNUstep don't
use GNUstep features at all, and those that use GNUstep features rely on
GNUstep.  I am not aware of any that don't rely on GNUstep, but that use
GNUstep features when present.

There seems to be only a handful of dockapps that use .app, though, so
if you see a package that says .app, chances are that it's a GNUstep
program.  And nearly all GNUstep programs say .app.

The .app comes from the NeXT nomenclature of programs.

-- 
Hubert Chan - email  Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA   (Key available at wwwkeys.pgp.net)
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


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



Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Peter Samuelson

[Nathanael Nerode]
 So -- point me to the correct parts of the installer.  I don't know
 where to find this anna.

svn://svn.debian.org/d-i/trunk/packages/anna


signature.asc
Description: Digital signature


Re: The bigger issue is badly licensed blobs (was Re: Firmware poll

2006-08-30 Thread Nathanael Nerode
Steve Langasek wrote:

 On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote:
snip

 Actually, letting an overworked team of four with (to my knowledge) zero
 legal expertise settle questions of legal liability is pretty absurd too.
 
 They are the team responsible for vetting the legality of what's
 distributed
 on the mirrors.  None of them have any legal expertise to my knowledge;
 but they do know where the lawyers are if they have questions,

Well, that's good!  Do they really have the hotline to the lawyers? 
Excellent!  I hope they actually use it occasionally; I've never heard of
them doing so, so if they have gotten any legal opinions, they've kept
them secret.  (Dammit, when Debian developers attempted to get legal advice
on trademark policy, it sunk into a black hole.  The advice never really 
came back, after several years.)

 and they 
 *are* the ones in the hot seat(s).

Meaning that they are personally liable and the rest of the Debian
developers aren't?  :-)

I'd love to see a legal opinion from the SPI lawyers regarding who would be
liable if Debian did commit copyright infringment (or whatever) and someone
sued.

It seems to me that the developers have entrusted the ftpmasters with
the responsibility of guarding Debian's funds and property against a
copyright infringment lawsuit.  Is that the general feeling of the
developers?  Are the ftpmasters comfortable with that responsibility?  If
so, my proverbial hat is off to them.

 Should the ftpmasters, who have even less legal expertise,
 
 Judging by some of the nonsense that debian-legal is typically riddled
 with, if I were an ftpmaster I would find that claim insulting.

There is at least one laywer who posts regularly.  Which counts as some 
legal expertise, and which is exactly what I was referring to when I 
said very little.

 The only claim to expertise that debian-legal has is in the area of
 analyzing license terms and how they stack up against the requirements of
 the DFSG.  That is an important function, but it is *not* legal expertise.

See above.

-- 
Nathanael Nerode  [EMAIL PROTECTED]

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...


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



Accepted steghide 0.5.1-8 (source i386)

2006-08-30 Thread Ola Lundqvist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 07:54:24 +0200
Source: steghide
Binary: steghide
Architecture: source i386
Version: 0.5.1-8
Distribution: unstable
Urgency: low
Maintainer: Ola Lundqvist [EMAIL PROTECTED]
Changed-By: Ola Lundqvist [EMAIL PROTECTED]
Description: 
 steghide   - A steganography hiding tool
Closes: 360479
Changes: 
 steghide (0.5.1-8) unstable; urgency=low
 .
   * Updated to standards version 3.7.2.
   * Maintainer upload, closes: #360479.
   * Updated to debhelper 4 compatibility.
Files: 
 ccdbe49cf33b111ad38cd32f035d353c 627 misc optional steghide_0.5.1-8.dsc
 08c9e214cfb016f70f84413cbc8ce3a5 90496 misc optional steghide_0.5.1-8.diff.gz
 0adc54c1e8783cf5282f0873ea911e5f 174420 misc optional steghide_0.5.1-8_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9SlxGKGxzw/lPdkRApvuAJ9Sst78XzfWzITtBd38AU7UfZIhvACgigx+
P5kQDrEdy96qeHDDlQN8wxQ=
=/L7r
-END PGP SIGNATURE-


Accepted:
steghide_0.5.1-8.diff.gz
  to pool/main/s/steghide/steghide_0.5.1-8.diff.gz
steghide_0.5.1-8.dsc
  to pool/main/s/steghide/steghide_0.5.1-8.dsc
steghide_0.5.1-8_i386.deb
  to pool/main/s/steghide/steghide_0.5.1-8_i386.deb


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



Accepted libemail-foldertype-perl 0.812-1 (source all)

2006-08-30 Thread Michael Ablassmeier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 06:54:50 +0200
Source: libemail-foldertype-perl
Binary: libemail-foldertype-perl
Architecture: source all
Version: 0.812-1
Distribution: unstable
Urgency: low
Maintainer: Michael Ablassmeier [EMAIL PROTECTED]
Changed-By: Michael Ablassmeier [EMAIL PROTECTED]
Description: 
 libemail-foldertype-perl - determine the type of a mail folder
Changes: 
 libemail-foldertype-perl (0.812-1) unstable; urgency=low
 .
   * New upstream release
   * Add new README file to debian/docs
Files: 
 91fc981be72a3b12d780ed19ac7ef826 685 perl optional 
libemail-foldertype-perl_0.812-1.dsc
 6f64afac7fd2f0f49b81bc6ee9002544 12142 perl optional 
libemail-foldertype-perl_0.812.orig.tar.gz
 6a12682f5806fc1196fcd4273eb4d23e 1850 perl optional 
libemail-foldertype-perl_0.812-1.diff.gz
 8fab39b6829e7ac5516e41c6889129f0 14586 perl optional 
libemail-foldertype-perl_0.812-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9S0aEFV7g4B8rCURAnf9AJ0QqakEmcjSO/hhjRcDGjji/hhqOgCePd/K
ipqeYRQL9OuN1ebEE95j+ps=
=9Y4U
-END PGP SIGNATURE-


Accepted:
libemail-foldertype-perl_0.812-1.diff.gz
  to 
pool/main/libe/libemail-foldertype-perl/libemail-foldertype-perl_0.812-1.diff.gz
libemail-foldertype-perl_0.812-1.dsc
  to 
pool/main/libe/libemail-foldertype-perl/libemail-foldertype-perl_0.812-1.dsc
libemail-foldertype-perl_0.812-1_all.deb
  to 
pool/main/libe/libemail-foldertype-perl/libemail-foldertype-perl_0.812-1_all.deb
libemail-foldertype-perl_0.812.orig.tar.gz
  to 
pool/main/libe/libemail-foldertype-perl/libemail-foldertype-perl_0.812.orig.tar.gz


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



Accepted xt 0.9.1-8 (source i386)

2006-08-30 Thread Ola Lundqvist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 08:03:01 +0200
Source: xt
Binary: xt
Architecture: source i386
Version: 0.9.1-8
Distribution: unstable
Urgency: low
Maintainer: Ola Lundqvist [EMAIL PROTECTED]
Changed-By: Ola Lundqvist [EMAIL PROTECTED]
Description: 
 xt - A graphical traceroute
Closes: 346773 368091
Changes: 
 xt (0.9.1-8) unstable; urgency=low
 .
   * Updated to standards version 3.7.2.
   * Updated dependency for debhelper to version 4.
   * Maintainer upload, closes: #346773.
   * Correction so the desktop file is installed properly, closes: #368091.
 Thanks to Barry deFreese [EMAIL PROTECTED] that did the changes in
 Ubuntu that I have used to fix this.
Files: 
 28aff6d6a22aea5f4e00320922cfbeba 687 x11 optional xt_0.9.1-8.dsc
 605b4b46e70a49394128d4e64f52bc14 178788 x11 optional xt_0.9.1-8.diff.gz
 1896b2fceec501976c0437932fd52d95 938606 x11 optional xt_0.9.1-8_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9Sz4GKGxzw/lPdkRAljWAJwKLUYCTF4qdFsv1W/XhSEg5r3r6gCfXUok
hxCwAG2xJWyzQw68cNuIoA8=
=pPiU
-END PGP SIGNATURE-


Accepted:
xt_0.9.1-8.diff.gz
  to pool/main/x/xt/xt_0.9.1-8.diff.gz
xt_0.9.1-8.dsc
  to pool/main/x/xt/xt_0.9.1-8.dsc
xt_0.9.1-8_i386.deb
  to pool/main/x/xt/xt_0.9.1-8_i386.deb


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



Accepted tuareg-mode 1.46.1-1 (source all)

2006-08-30 Thread Ralf Treinen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 29 Aug 2006 09:07:28 +0200
Source: tuareg-mode
Binary: tuareg-mode
Architecture: source all
Version: 1.46.1-1
Distribution: unstable
Urgency: low
Maintainer: Debian OCaml Maintainers debian-ocaml-maint@lists.debian.org
Changed-By: Ralf Treinen [EMAIL PROTECTED]
Description: 
 tuareg-mode - An emacs-mode for ocaml programs
Changes: 
 tuareg-mode (1.46.1-1) unstable; urgency=low
 .
   * New upstream release.
Files: 
 2f8861bb019c58dac0fc1f39a93183ff 873 devel optional tuareg-mode_1.46.1-1.dsc
 cc520b975f7dcdafd7730a6fbf074dd9 55297 devel optional 
tuareg-mode_1.46.1.orig.tar.gz
 cf9c40424eab5eada88477196380a548 6446 devel optional 
tuareg-mode_1.46.1-1.diff.gz
 656a526302340bacb70e5c9e90b53a42 57660 devel optional 
tuareg-mode_1.46.1-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9TRRtzWmSeC6BMERAshAAJ4titsx24zsNIYgUnsrQAts9YSV6gCeMA1T
rCas5mSIxN22QWykCmTzy5k=
=N1kK
-END PGP SIGNATURE-


Accepted:
tuareg-mode_1.46.1-1.diff.gz
  to pool/main/t/tuareg-mode/tuareg-mode_1.46.1-1.diff.gz
tuareg-mode_1.46.1-1.dsc
  to pool/main/t/tuareg-mode/tuareg-mode_1.46.1-1.dsc
tuareg-mode_1.46.1-1_all.deb
  to pool/main/t/tuareg-mode/tuareg-mode_1.46.1-1_all.deb
tuareg-mode_1.46.1.orig.tar.gz
  to pool/main/t/tuareg-mode/tuareg-mode_1.46.1.orig.tar.gz


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



Accepted pytone 2.3.0-1.2 (source amd64)

2006-08-30 Thread Pierre Habouzit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 09:52:01 +0200
Source: pytone
Binary: pytone
Architecture: source amd64
Version: 2.3.0-1.2
Distribution: unstable
Urgency: low
Maintainer: Alexander Wirt [EMAIL PROTECTED]
Changed-By: Pierre Habouzit [EMAIL PROTECTED]
Description: 
 pytone - Music jukebox with advanced features for DJs and a text-mode user
Changes: 
 pytone (2.3.0-1.2) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Redo the previous NMU correctly:
 + build for the current python (no more python2.3 references).
 + use python-support.
 + install all in /usr/lib/pytone.
 + make /usr/bin/pythone{,ctl} be links instead of scripts, no more
   dpatche's.
Files: 
 dbf702b6abbbc4b8651c74b348a44bdd 620 sound optional pytone_2.3.0-1.2.dsc
 054574fbcf7e11c4719da17075584044 5709 sound optional pytone_2.3.0-1.2.diff.gz
 7934b007afd15fd1333b0912e58d83cb 167344 sound optional 
pytone_2.3.0-1.2_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9UXXvGr7W6HudhwRAkrIAKCkyz4ibfYO9Z/JZKCjlLwxox6lLACdH5nn
VqFz3Ajwrrb5tBFUEsnuaps=
=/qQB
-END PGP SIGNATURE-


Accepted:
pytone_2.3.0-1.2.diff.gz
  to pool/main/p/pytone/pytone_2.3.0-1.2.diff.gz
pytone_2.3.0-1.2.dsc
  to pool/main/p/pytone/pytone_2.3.0-1.2.dsc
pytone_2.3.0-1.2_amd64.deb
  to pool/main/p/pytone/pytone_2.3.0-1.2_amd64.deb


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



Accepted sylpheed-claws-gtk2 2.5.0~rc2-2 (source all amd64)

2006-08-30 Thread Ricardo Mones
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 08:53:48 +0200
Source: sylpheed-claws-gtk2
Binary: sylpheed-claws-gtk2-spamassassin sylpheed-claws-gtk2-plugins 
sylpheed-claws-gtk2 sylpheed-claws-gtk2-i18n sylpheed-claws-gtk2-pgpinline 
libsylpheed-claws-gtk2-dev sylpheed-claws-gtk2-pgpmime 
sylpheed-claws-gtk2-dillo-viewer sylpheed-claws-gtk2-clamav 
sylpheed-claws-gtk2-trayicon sylpheed-claws-gtk2-doc
Architecture: source amd64 all
Version: 2.5.0~rc2-2
Distribution: unstable
Urgency: low
Maintainer: Ricardo Mones [EMAIL PROTECTED]
Changed-By: Ricardo Mones [EMAIL PROTECTED]
Description: 
 libsylpheed-claws-gtk2-dev - Development files for Sylpheed-Claws GTK2 plugins
 sylpheed-claws-gtk2 - Fast, lightweight and user-friendly GTK2 based email 
client
 sylpheed-claws-gtk2-clamav - Clam AntiVirus plugin for the Sylpheed-Claws GTK2 
mail client
 sylpheed-claws-gtk2-dillo-viewer - HTML viewer plugin for Sylpheed-Claws GTK2 
using Dillo
 sylpheed-claws-gtk2-doc - User documentation for Sylpheed-Claws GTK2 mailer
 sylpheed-claws-gtk2-i18n - Locale data for Sylpheed-Claws GTK2 (i18n support)
 sylpheed-claws-gtk2-pgpinline - PGP/inline plugin for Sylpheed-Claws GTK2
 sylpheed-claws-gtk2-pgpmime - PGP/MIME plugin for Sylpheed-Claws GTK2
 sylpheed-claws-gtk2-plugins - Installs plugins for the Sylpheed-Claws GTK2 
mail client
 sylpheed-claws-gtk2-spamassassin - SpamAssassin plugin for Sylpheed-Claws GTK2
 sylpheed-claws-gtk2-trayicon - Notification area plugin for Sylpheed-Claws GTK2
Changes: 
 sylpheed-claws-gtk2 (2.5.0~rc2-2) unstable; urgency=low
 .
   * debian/control
   - fixed gettext versioned depend, 0.15 is not required - my fault :(
Files: 
 112f6300f637f3ee40f475bf8e0c19f1 1401 mail optional 
sylpheed-claws-gtk2_2.5.0~rc2-2.dsc
 76bbe03b41c1cde0fe41a49339b7d7bf 37426 mail optional 
sylpheed-claws-gtk2_2.5.0~rc2-2.diff.gz
 f64d8f9ccfac9bf89ab71971e7509617 1325508 mail optional 
sylpheed-claws-gtk2_2.5.0~rc2-2_amd64.deb
 d6906bd1c43e6acff88559db09e77cd3 206060 devel optional 
libsylpheed-claws-gtk2-dev_2.5.0~rc2-2_amd64.deb
 8ddb097e17e0295408a16f72a4051314 105684 mail optional 
sylpheed-claws-gtk2-plugins_2.5.0~rc2-2_all.deb
 6d58a962914ad60e3dcba016c24a88b1 114720 mail optional 
sylpheed-claws-gtk2-clamav_2.5.0~rc2-2_amd64.deb
 d7405f412b508809302b0722c1f00c9e 112150 mail optional 
sylpheed-claws-gtk2-dillo-viewer_2.5.0~rc2-2_amd64.deb
 587830900794cda18a4e44d93c57de22 126508 mail optional 
sylpheed-claws-gtk2-spamassassin_2.5.0~rc2-2_amd64.deb
 e08f9205df6fdc236fb005b12c5d12f7 117806 mail optional 
sylpheed-claws-gtk2-trayicon_2.5.0~rc2-2_amd64.deb
 ffd40c9040fa9da7080afed2a8dafc54 137888 mail optional 
sylpheed-claws-gtk2-pgpmime_2.5.0~rc2-2_amd64.deb
 eb30a8c07bc708ce27e0edfacca3e143 115496 mail optional 
sylpheed-claws-gtk2-pgpinline_2.5.0~rc2-2_amd64.deb
 f595d75518dbc31e5c1bedf9a2aaa078 1551988 mail optional 
sylpheed-claws-gtk2-i18n_2.5.0~rc2-2_all.deb
 049f63676879b822867f9ca2289fd756 925084 doc optional 
sylpheed-claws-gtk2-doc_2.5.0~rc2-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9U0WLARVQsm1XawRAsC3AJ9aGYsQuAYVu8iS/DgMsr+MwBwozACfXwCo
U7kgWM0stZHXcGLbqiNjg4c=
=QUl2
-END PGP SIGNATURE-


Accepted:
libsylpheed-claws-gtk2-dev_2.5.0~rc2-2_amd64.deb
  to 
pool/main/s/sylpheed-claws-gtk2/libsylpheed-claws-gtk2-dev_2.5.0~rc2-2_amd64.deb
sylpheed-claws-gtk2-clamav_2.5.0~rc2-2_amd64.deb
  to 
pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2-clamav_2.5.0~rc2-2_amd64.deb
sylpheed-claws-gtk2-dillo-viewer_2.5.0~rc2-2_amd64.deb
  to 
pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2-dillo-viewer_2.5.0~rc2-2_amd64.deb
sylpheed-claws-gtk2-doc_2.5.0~rc2-2_all.deb
  to pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2-doc_2.5.0~rc2-2_all.deb
sylpheed-claws-gtk2-i18n_2.5.0~rc2-2_all.deb
  to 
pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2-i18n_2.5.0~rc2-2_all.deb
sylpheed-claws-gtk2-pgpinline_2.5.0~rc2-2_amd64.deb
  to 
pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2-pgpinline_2.5.0~rc2-2_amd64.deb
sylpheed-claws-gtk2-pgpmime_2.5.0~rc2-2_amd64.deb
  to 
pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2-pgpmime_2.5.0~rc2-2_amd64.deb
sylpheed-claws-gtk2-plugins_2.5.0~rc2-2_all.deb
  to 
pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2-plugins_2.5.0~rc2-2_all.deb
sylpheed-claws-gtk2-spamassassin_2.5.0~rc2-2_amd64.deb
  to 
pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2-spamassassin_2.5.0~rc2-2_amd64.deb
sylpheed-claws-gtk2-trayicon_2.5.0~rc2-2_amd64.deb
  to 
pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2-trayicon_2.5.0~rc2-2_amd64.deb
sylpheed-claws-gtk2_2.5.0~rc2-2.diff.gz
  to pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2_2.5.0~rc2-2.diff.gz
sylpheed-claws-gtk2_2.5.0~rc2-2.dsc
  to pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2_2.5.0~rc2-2.dsc
sylpheed-claws-gtk2_2.5.0~rc2-2_amd64.deb
  to pool/main/s/sylpheed-claws-gtk2/sylpheed-claws-gtk2_2.5.0~rc2-2_amd64.deb


-- 
To UNSUBSCRIBE, email 

Accepted unzip 5.52-9 (source powerpc)

2006-08-30 Thread Santiago Vila
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 10:34:24 +0200
Source: unzip
Binary: unzip
Architecture: source powerpc
Version: 5.52-9
Distribution: unstable
Urgency: low
Maintainer: Santiago Vila [EMAIL PROTECTED]
Changed-By: Santiago Vila [EMAIL PROTECTED]
Description: 
 unzip  - De-archiver for .zip files
Closes: 192253
Changes: 
 unzip (5.52-9) unstable; urgency=low
 .
   * Added appropriate compiler flags for Large File Support (Closes: #192253).
 This procedure is blessed by upstream in the FAQ, and as a result,
 some .zip archives may now be uncompressed using Debian unzip.
 For those which still may not, please test unzip 6.0 beta.
Files: 
 0f7efe2951516047b3b0b3a07dc9e9fd 517 utils optional unzip_5.52-9.dsc
 38554f48dcfb54fcfd1067f465dafa02 11080 utils optional unzip_5.52-9.diff.gz
 46db3757ad08b66a14304ab74a4ca164 163534 utils optional unzip_5.52-9_powerpc.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9VDTd9Uuvj7yPNYRAlkmAKCG7exNcQsz8Vr1ANkcu6cdnHwY8gCfUD+N
SncgAVm5ifbpTofn1eELnqo=
=3wFl
-END PGP SIGNATURE-


Accepted:
unzip_5.52-9.diff.gz
  to pool/main/u/unzip/unzip_5.52-9.diff.gz
unzip_5.52-9.dsc
  to pool/main/u/unzip/unzip_5.52-9.dsc
unzip_5.52-9_powerpc.deb
  to pool/main/u/unzip/unzip_5.52-9_powerpc.deb


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



Accepted gnubiff 2.2.2-3 (source i386)

2006-08-30 Thread Roland Stigge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 10:50:37 +0200
Source: gnubiff
Binary: gnubiff
Architecture: source i386
Version: 2.2.2-3
Distribution: unstable
Urgency: low
Maintainer: Roland Stigge [EMAIL PROTECTED]
Changed-By: Roland Stigge [EMAIL PROTECTED]
Description: 
 gnubiff- A mail notification program for GNOME (and others)
Changes: 
 gnubiff (2.2.2-3) unstable; urgency=low
 .
   * src/decoding.cc: Adjusted previous fix to upstream's approach
 (to prevent incompatibility)
Files: 
 444b58f5b7c68484e8fcd10c514d701c 708 mail optional gnubiff_2.2.2-3.dsc
 b7d05f6cb3942df98cfb8ec904873ea2 5124 mail optional gnubiff_2.2.2-3.diff.gz
 5c33154d474cdaf8ee14ab961133ba7f 510288 mail optional gnubiff_2.2.2-3_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9VQKcaH/YBv43g8RAlZ4AJ93CdTYjYPH4ZZuoGcv4FGGJ5TpGQCcDFpC
QJK7gzx3aiU12gjlvBguo4k=
=GNoR
-END PGP SIGNATURE-


Accepted:
gnubiff_2.2.2-3.diff.gz
  to pool/main/g/gnubiff/gnubiff_2.2.2-3.diff.gz
gnubiff_2.2.2-3.dsc
  to pool/main/g/gnubiff/gnubiff_2.2.2-3.dsc
gnubiff_2.2.2-3_i386.deb
  to pool/main/g/gnubiff/gnubiff_2.2.2-3_i386.deb


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



Accepted systemtap 0.0.20060826-1 (source i386)

2006-08-30 Thread Eugeniy Meshcheryakov
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 11:20:39 +0200
Source: systemtap
Binary: systemtap
Architecture: source i386
Version: 0.0.20060826-1
Distribution: unstable
Urgency: low
Maintainer: Eugeniy Meshcheryakov [EMAIL PROTECTED]
Changed-By: Eugeniy Meshcheryakov [EMAIL PROTECTED]
Description: 
 systemtap  - instrumentation system for Linux 2.6
Changes: 
 systemtap (0.0.20060826-1) unstable; urgency=low
 .
   * New upstream snapshot
   * Removed patches (applied upstream):
 - 03-systemtap-manpages
 - 08-string-const-to-charp-fix
Files: 
 60f4fa5d459bbb6031f47b1364597295 759 devel optional 
systemtap_0.0.20060826-1.dsc
 4fd58116f5cd4afe0a8303d4cf283f6e 548161 devel optional 
systemtap_0.0.20060826.orig.tar.gz
 556cfc3772159fa625cae45e5d99e387 4222 devel optional 
systemtap_0.0.20060826-1.diff.gz
 994ffb6eda8572d731a0c8746c304c70 563310 devel optional 
systemtap_0.0.20060826-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9VjpKaC6+zmozOIRAuPYAJ9h9/peH7NM5/xYzaaq2xswvKWiFQCePqKG
+xat7jM9iVtbVxpsK6vojyg=
=qo2e
-END PGP SIGNATURE-


Accepted:
systemtap_0.0.20060826-1.diff.gz
  to pool/main/s/systemtap/systemtap_0.0.20060826-1.diff.gz
systemtap_0.0.20060826-1.dsc
  to pool/main/s/systemtap/systemtap_0.0.20060826-1.dsc
systemtap_0.0.20060826-1_i386.deb
  to pool/main/s/systemtap/systemtap_0.0.20060826-1_i386.deb
systemtap_0.0.20060826.orig.tar.gz
  to pool/main/s/systemtap/systemtap_0.0.20060826.orig.tar.gz


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



Accepted pymol 0.98+0.99rc6-1.1 (source amd64)

2006-08-30 Thread Pierre Habouzit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 11:09:00 +0200
Source: pymol
Binary: pymol
Architecture: source amd64
Version: 0.98+0.99rc6-1.1
Distribution: unstable
Urgency: low
Maintainer: Michael Banck [EMAIL PROTECTED]
Changed-By: Pierre Habouzit [EMAIL PROTECTED]
Description: 
 pymol  - An OpenGL Molecular Graphics System written in Python
Closes: 380910
Changes: 
 pymol (0.98+0.99rc6-1.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Update packate to the last python policy (Closes: 380910):
 + use dh_pysupport.
 + add 11_fix__cmd_import.dpatch to fix an import that does not behaves
   well.
 + adapt the wrapper to the new path's.
   * Bump Standards-Version to 3.7.2.
   * Bump DH_COMPAT to 4.
   * Fix more files that have wrong executable bits set.
Files: 
 a3a32073c468e1bd2cd156a5ce5f20df 698 science optional 
pymol_0.98+0.99rc6-1.1.dsc
 cc157bed5216a7a004ad537558ef8165 14200 science optional 
pymol_0.98+0.99rc6-1.1.diff.gz
 559dda70ea071f7818967353d848fca2 3965722 science optional 
pymol_0.98+0.99rc6-1.1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9WBWvGr7W6HudhwRAl6dAJ4wHcriDmR596CBcqHOyGgYY3m1JACdEc14
f0Mznocj/J5C8nBEAbx+sgI=
=lDMb
-END PGP SIGNATURE-


Accepted:
pymol_0.98+0.99rc6-1.1.diff.gz
  to pool/main/p/pymol/pymol_0.98+0.99rc6-1.1.diff.gz
pymol_0.98+0.99rc6-1.1.dsc
  to pool/main/p/pymol/pymol_0.98+0.99rc6-1.1.dsc
pymol_0.98+0.99rc6-1.1_amd64.deb
  to pool/main/p/pymol/pymol_0.98+0.99rc6-1.1_amd64.deb


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



Accepted libmodule-corelist-perl 2.07-1 (source all)

2006-08-30 Thread eloy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 11:32:21 +0200
Source: libmodule-corelist-perl
Binary: libmodule-corelist-perl
Architecture: source all
Version: 2.07-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group [EMAIL PROTECTED]
Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED]
Description: 
 libmodule-corelist-perl - what modules shipped with versions of perl
Changes: 
 libmodule-corelist-perl (2.07-1) unstable; urgency=low
 .
   * New upstream release
Files: 
 6fea212928abfae2fed9c4fc55b1fbc8 750 perl optional 
libmodule-corelist-perl_2.07-1.dsc
 53cb027ee6895d162bbb8b12182e0ae7 37015 perl optional 
libmodule-corelist-perl_2.07.orig.tar.gz
 0b80ff2021299024c0813f7eb5c8d62b 2152 perl optional 
libmodule-corelist-perl_2.07-1.diff.gz
 704ed6b61b6881537092e01b9c14a02b 43958 perl optional 
libmodule-corelist-perl_2.07-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9WEa+NMfSd6w7DERAqs4AKC7/Ah+RZLEFd/lR/nsA2fI2cuX2QCeOW5i
/Ftyepg2TUEHvDcVCSxddxc=
=vLXB
-END PGP SIGNATURE-


Accepted:
libmodule-corelist-perl_2.07-1.diff.gz
  to 
pool/main/libm/libmodule-corelist-perl/libmodule-corelist-perl_2.07-1.diff.gz
libmodule-corelist-perl_2.07-1.dsc
  to pool/main/libm/libmodule-corelist-perl/libmodule-corelist-perl_2.07-1.dsc
libmodule-corelist-perl_2.07-1_all.deb
  to 
pool/main/libm/libmodule-corelist-perl/libmodule-corelist-perl_2.07-1_all.deb
libmodule-corelist-perl_2.07.orig.tar.gz
  to 
pool/main/libm/libmodule-corelist-perl/libmodule-corelist-perl_2.07.orig.tar.gz


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



Accepted soap-lite 0.69-1 (source all)

2006-08-30 Thread eloy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 11:23:46 +0200
Source: soap-lite
Binary: libsoap-lite-perl
Architecture: source all
Version: 0.69-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group [EMAIL PROTECTED]
Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED]
Description: 
 libsoap-lite-perl - Client and server side SOAP implementation
Changes: 
 soap-lite (0.69-1) unstable; urgency=low
 .
   * New upstream release
Files: 
 404f2e41dadfab0aeefa0831974ba24b 978 perl optional soap-lite_0.69-1.dsc
 24e0c656a6a7047c91f7f3f3b5c36513 238150 perl optional 
soap-lite_0.69.orig.tar.gz
 03b99782368c9055e19f97deec6b1d18 4002 perl optional soap-lite_0.69-1.diff.gz
 dcd46cc62a0c51458e512d5a383bc7d7 399366 perl optional 
libsoap-lite-perl_0.69-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9Voe+NMfSd6w7DERAm6JAKCn35VSGsLm5qPwTKi08ivpvSCIpACgwQSA
aG29qyZFdEJm1A/CbamHyLQ=
=eiGm
-END PGP SIGNATURE-


Accepted:
libsoap-lite-perl_0.69-1_all.deb
  to pool/main/s/soap-lite/libsoap-lite-perl_0.69-1_all.deb
soap-lite_0.69-1.diff.gz
  to pool/main/s/soap-lite/soap-lite_0.69-1.diff.gz
soap-lite_0.69-1.dsc
  to pool/main/s/soap-lite/soap-lite_0.69-1.dsc
soap-lite_0.69.orig.tar.gz
  to pool/main/s/soap-lite/soap-lite_0.69.orig.tar.gz


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



Accepted collatinus 7.14-1.1 (source all)

2006-08-30 Thread Pierre Habouzit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 12:30:10 +0200
Source: collatinus
Binary: collatinus collatinus-doc
Architecture: source all
Version: 7.14-1.1
Distribution: unstable
Urgency: low
Maintainer: Georges Khaznadar [EMAIL PROTECTED]
Changed-By: Pierre Habouzit [EMAIL PROTECTED]
Description: 
 collatinus - lemmatisation of latin text
 collatinus-doc - documentation for collatinus
Closes: 380776
Changes: 
 collatinus (7.14-1.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Update package to the last python policy (Closes: #380776).
   * Bump Standards-Version to 3.7.2.
   * Move debhelper to Build-Depends.
   * collatinus-data has no sense: collatinus is already arch:all, so merge the
 packages.
   * generate the lematta at build time, instead of install time (it was not
 even removed in the prerm !)
Files: 
 8a707eb0ce8ed87f23547eb800e23d0f 666 text optional collatinus_7.14-1.1.dsc
 e7683d40333477a444ac58912712ae5f 3111 text optional collatinus_7.14-1.1.diff.gz
 61b38fdc42ac5802a8616007a6a9eedb 519590 text optional 
collatinus_7.14-1.1_all.deb
 69b878faaf96f9471dd4ce2eb41ffe38 78306 text optional 
collatinus-doc_7.14-1.1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9XT2vGr7W6HudhwRAufhAJ4zoref4pjW9K+t6Ms/R8VsZnm6YgCeOFIC
AyGwqgqirkoYYccHyIjONGM=
=7Ex3
-END PGP SIGNATURE-


Accepted:
collatinus-doc_7.14-1.1_all.deb
  to pool/main/c/collatinus/collatinus-doc_7.14-1.1_all.deb
collatinus_7.14-1.1.diff.gz
  to pool/main/c/collatinus/collatinus_7.14-1.1.diff.gz
collatinus_7.14-1.1.dsc
  to pool/main/c/collatinus/collatinus_7.14-1.1.dsc
collatinus_7.14-1.1_all.deb
  to pool/main/c/collatinus/collatinus_7.14-1.1_all.deb


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



Accepted soundconverter 0.8.7-2 (source all)

2006-08-30 Thread Lars Wirzenius
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 14:00:59 +0300
Source: soundconverter
Binary: soundconverter
Architecture: source all
Version: 0.8.7-2
Distribution: unstable
Urgency: low
Maintainer: Lars Wirzenius [EMAIL PROTECTED]
Changed-By: Lars Wirzenius [EMAIL PROTECTED]
Description: 
 soundconverter - convert sound files to other formats
Closes: 382279 385181
Changes: 
 soundconverter (0.8.7-2) unstable; urgency=low
 .
   * debian/control: Added missing dependency gstreamer0.8-gnomevfs.
 Thanks, Martin Schulze. Closes: #382279.
   * soundconverter.py: Changed the charset declaration from latin-1
 to iso-8859-1. Thanks, Mario Iseli. Closes: #385181.
   * debian/control: Added an XS-Python-Version header.
Files: 
 eb528314209beaa768dfca5e643a0b77 606 gnome optional soundconverter_0.8.7-2.dsc
 c691d4f55160198a3af0adc11bbf3e9d 2565 gnome optional 
soundconverter_0.8.7-2.diff.gz
 814507968a89a653fe934e54fa75f1ac 45660 gnome optional 
soundconverter_0.8.7-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9XGpH7uVvy2azI4RAoyUAKCFOPxmMZmsrNXkcIO6LEbc5C00lwCeIfwZ
Mp7ukcc+C12zLl8vA2WeCoQ=
=DSur
-END PGP SIGNATURE-


Accepted:
soundconverter_0.8.7-2.diff.gz
  to pool/main/s/soundconverter/soundconverter_0.8.7-2.diff.gz
soundconverter_0.8.7-2.dsc
  to pool/main/s/soundconverter/soundconverter_0.8.7-2.dsc
soundconverter_0.8.7-2_all.deb
  to pool/main/s/soundconverter/soundconverter_0.8.7-2_all.deb


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



Accepted yum 2.4.0-3.1 (source all)

2006-08-30 Thread Pierre Habouzit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 13:43:22 +0200
Source: yum
Binary: yum
Architecture: source all
Version: 2.4.0-3.1
Distribution: unstable
Urgency: medium
Maintainer: Anand Kumria [EMAIL PROTECTED]
Changed-By: Pierre Habouzit [EMAIL PROTECTED]
Description: 
 yum- Advanced front-end for rpm
Closes: 380993
Changes: 
 yum (2.4.0-3.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Update package to the last python policy (Closes: #380993).
   * Urgency set to medium for RC bug fix.
   * Bump Standards-Version to 3.7.2.
   * Fixing bashism in docs/Makefile.
   * removing debian/*.ex files.
Files: 
 de3106a17851698d2fff89d6955d0b40 588 admin extra yum_2.4.0-3.1.dsc
 2ebd68aa01ac3dafba5f12c4b1ef 3366 admin extra yum_2.4.0-3.1.diff.gz
 5dc1257800dbb360f5a37ac5679fee5f 203358 admin extra yum_2.4.0-3.1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9XtgvGr7W6HudhwRAsAtAJsGMKsmMkSaL2Rv8zQbSlMoWUIctACfZwN1
NjqLjQ5t5H+j4tlEOi68v6I=
=ol8c
-END PGP SIGNATURE-


Accepted:
yum_2.4.0-3.1.diff.gz
  to pool/main/y/yum/yum_2.4.0-3.1.diff.gz
yum_2.4.0-3.1.dsc
  to pool/main/y/yum/yum_2.4.0-3.1.dsc
yum_2.4.0-3.1_all.deb
  to pool/main/y/yum/yum_2.4.0-3.1_all.deb


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



Accepted kid 0.9.3-1 (source all)

2006-08-30 Thread Ross Burton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 09:08:29 +0100
Source: kid
Binary: python-kid
Architecture: source all
Version: 0.9.3-1
Distribution: unstable
Urgency: low
Maintainer: Ross Burton [EMAIL PROTECTED]
Changed-By: Ross Burton [EMAIL PROTECTED]
Description: 
 python-kid - simple Pythonic template language for XML based vocabularies
Closes: 368979 376536
Changes: 
 kid (0.9.3-1) unstable; urgency=low
 .
   * New upstream release (closes: #376536, #368979)
   * Update upstream URL.
Files: 
 019c4a77cdf429a99bc9f0efab4f9286 814 python optional kid_0.9.3-1.dsc
 8a2fa657183b01ab8f4fb5f79704a013 234467 python optional kid_0.9.3.orig.tar.gz
 b67703eb7880da8a3b7928ed2c11dd67 4187 python optional kid_0.9.3-1.diff.gz
 6fcf1eff6c05350676f1fa832639c04c 237382 python optional 
python-kid_0.9.3-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFE9V/xLQnkR9C0M98RAoxHAJwLoaGMXi33EnHcyGZA8mj70cyQlwCfRUbw
AE7U7uO4gdyHUYdXTRXNVoo=
=a4Q3
-END PGP SIGNATURE-


Accepted:
kid_0.9.3-1.diff.gz
  to pool/main/k/kid/kid_0.9.3-1.diff.gz
kid_0.9.3-1.dsc
  to pool/main/k/kid/kid_0.9.3-1.dsc
kid_0.9.3.orig.tar.gz
  to pool/main/k/kid/kid_0.9.3.orig.tar.gz
python-kid_0.9.3-1_all.deb
  to pool/main/k/kid/python-kid_0.9.3-1_all.deb


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



Accepted mondo 2.09-2 (source all amd64)

2006-08-30 Thread Andree Leidenfrost
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 15:44:48 +1000
Source: mondo
Binary: mondo-doc mondo
Architecture: source amd64 all
Version: 2.09-2
Distribution: unstable
Urgency: low
Maintainer: Andree Leidenfrost [EMAIL PROTECTED]
Changed-By: Andree Leidenfrost [EMAIL PROTECTED]
Description: 
 mondo  - powerful disaster recovery suite
 mondo-doc  - manual for Mondo, a powerful disaster recovery suite
Closes: 379966
Changes: 
 mondo (2.09-2) unstable; urgency=low
 .
   * Implemented and used new function mr_stresc() for properly escaping
 strings submitted to system() and popen. (Closes: #379966.)
   * Fixed compiler warning regarding the output of the result of
 ftello() by casting it to long long (and it's actually signed).
   * Ask whether post-nuke should be executed if it exists even if we are
 not in nuke mode.
   * Check for grub.conf being a symbolic link and resolve in stabgrub-me
 to avoid GRUB installation error if mountlist was changed. Requires
 readlink which is in mindi-busybox-1.2.1-2 - changed dependency
 accordingly.
   * Handle popen() errors in space_occupied_by_cd() and output log
 information. Fixes segmentation fault.
Files: 
 01f8e808048f1b193b282c8e4a7c143a 641 utils optional mondo_2.09-2.dsc
 baf279a18bf3fa14c85db0fce8ef193d 28438 utils optional mondo_2.09-2.diff.gz
 ad0aae66eb0a226ab58213e2bad24bcb 431184 utils optional mondo_2.09-2_amd64.deb
 3c71d15b98686bc29f460d512d03a5ec 1680350 doc optional mondo-doc_2.09-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD4DBQFE9SZRiLvX3b2IzawRAq70AJ97VXxAcjUCaQTiOJdtogJyua8TBACWI5ws
SbhmKWC2hkNh4zV1r4vbfw==
=mCoE
-END PGP SIGNATURE-


Accepted:
mondo-doc_2.09-2_all.deb
  to pool/main/m/mondo/mondo-doc_2.09-2_all.deb
mondo_2.09-2.diff.gz
  to pool/main/m/mondo/mondo_2.09-2.diff.gz
mondo_2.09-2.dsc
  to pool/main/m/mondo/mondo_2.09-2.dsc
mondo_2.09-2_amd64.deb
  to pool/main/m/mondo/mondo_2.09-2_amd64.deb


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



Accepted mindi-busybox 1.2.1-2 (source amd64)

2006-08-30 Thread Andree Leidenfrost
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 09:04:27 +1000
Source: mindi-busybox
Binary: mindi-busybox
Architecture: source amd64
Version: 1.2.1-2
Distribution: unstable
Urgency: low
Maintainer: Andree Leidenfrost [EMAIL PROTECTED]
Changed-By: Andree Leidenfrost [EMAIL PROTECTED]
Description: 
 mindi-busybox - Collection of shell utilities in a single executable for 
Mindi/Mo
Changes: 
 mindi-busybox (1.2.1-2) unstable; urgency=low
 .
   * Turned on readlink because we need it in mondo's stabgrub-me script.
Files: 
 3cd97f2d40a69cd97b008fc7981dc2f5 646 shells optional mindi-busybox_1.2.1-2.dsc
 e6f70813c17efb7c74744962c0d539c6 9165 shells optional 
mindi-busybox_1.2.1-2.diff.gz
 b2a2d470087428b0d96858118ce87412 783832 shells optional 
mindi-busybox_1.2.1-2_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9Mq9iLvX3b2IzawRAsBUAJ98qBll1TpHDC3lAh+Hv+GR1aNm+wCeJE0F
KRrULvAplFoTlwL0BP6a4Ts=
=HfN3
-END PGP SIGNATURE-


Accepted:
mindi-busybox_1.2.1-2.diff.gz
  to pool/main/m/mindi-busybox/mindi-busybox_1.2.1-2.diff.gz
mindi-busybox_1.2.1-2.dsc
  to pool/main/m/mindi-busybox/mindi-busybox_1.2.1-2.dsc
mindi-busybox_1.2.1-2_amd64.deb
  to pool/main/m/mindi-busybox/mindi-busybox_1.2.1-2_amd64.deb


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



Accepted cdebootstrap 0.3.13 (source amd64)

2006-08-30 Thread Bastian Blank
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 12:19:52 +
Source: cdebootstrap
Binary: cdebootstrap cdebootstrap-udeb
Architecture: source amd64
Version: 0.3.13
Distribution: unstable
Urgency: low
Maintainer: Bastian Blank [EMAIL PROTECTED]
Changed-By: Bastian Blank [EMAIL PROTECTED]
Description: 
 cdebootstrap - Bootstrap a Debian system
 cdebootstrap-udeb - Bootstrap a Debian system (udeb)
Changes: 
 cdebootstrap (0.3.13) unstable; urgency=low
 .
   * config:
 - Remove bootable flavour.
 - Use important priority for standard flavour in sid and etch.
 - Remove special etch config, it matches the sid one.
   * helper/cdebootstrap-helper-apt:
 - Don't consider a gzip compressed file an alternative of an bzip2
   compressed one.
   * src:
 - Support exclude of packages via config.
Files: 
 888a0f7712808691a8efaa82d214ee78 630 admin optional cdebootstrap_0.3.13.dsc
 edd9f983d0f060a4025e47b4924ad737 133693 admin optional 
cdebootstrap_0.3.13.tar.gz
 4f67161fa7a0f0c6d8e75b41d2f74965 26264 admin optional 
cdebootstrap_0.3.13_amd64.deb
 48aea10484d1072386d31f91c180657d 18814 debian-installer optional 
cdebootstrap-udeb_0.3.13_amd64.udeb
Package-Type: udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iEYEARECAAYFAkT1gugACgkQLkAIIn9ODhH/OwCgiT2/p6j4mkJLZ4fwuiDfYRgm
dRYAn3UT8No9210CjGF/clYbN7dlNqM+
=NCHy
-END PGP SIGNATURE-


Accepted:
cdebootstrap-udeb_0.3.13_amd64.udeb
  to pool/main/c/cdebootstrap/cdebootstrap-udeb_0.3.13_amd64.udeb
cdebootstrap_0.3.13.dsc
  to pool/main/c/cdebootstrap/cdebootstrap_0.3.13.dsc
cdebootstrap_0.3.13.tar.gz
  to pool/main/c/cdebootstrap/cdebootstrap_0.3.13.tar.gz
cdebootstrap_0.3.13_amd64.deb
  to pool/main/c/cdebootstrap/cdebootstrap_0.3.13_amd64.deb


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



Accepted tiger 1:3.2.1-32 (source i386)

2006-08-30 Thread Javier Fernandez-Sanguino Pen~a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 14:13:42 +0200
Source: tiger
Binary: tiger tiger-otheros
Architecture: source i386
Version: 1:3.2.1-32
Distribution: unstable
Urgency: low
Maintainer: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED]
Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED]
Description: 
 tiger  - Report system security vulnerabilities
 tiger-otheros - Scripts to run Tiger in other operating systems
Closes: 277533 320341 366919
Changes: 
 tiger (1:3.2.1-32) unstable; urgency=low
 .
   * Modify config so that it will attempt to create a working directory if
 it does not exist (Closes: #366919)
   * [scripts/check_rootkit] Introduce Tiger_CHKROOTKIT_ARGS so that
 admins can ajust the behaviour of CHKROOTKIT (defaults to '-q')
 (Closes: #320341)
   * Include output of chkrootkit when a file is INFECTED (Closes: #277533)
Files: 
 c7b91a404ca2b8f4fd6fd3d46cfbd47f 746 admin optional tiger_3.2.1-32.dsc
 540f4d4c36835bd758acbb1ad0529d84 457614 admin optional tiger_3.2.1-32.diff.gz
 9c663ce2724054a8d6a8bc17e5fd1d22 572378 admin optional tiger_3.2.1-32_i386.deb
 72be3d983a8ee3c2f7fde9f6209f310f 487890 admin optional 
tiger-otheros_3.2.1-32_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRPWE0vtEPvakNq0lAQIaAAP+J+nqM1d88K/CT9KcGID78ZXoOPNFwKAk
5GFJoJI8cRaDgmOO2/FQIxs0Mh2hrSdQVKf1ZtEXqf/6t7hFE4rhFcQsYPf6jy0s
ff0XGYvO8rKl5Vo1CdotLgy5od5y88/mR+32EW1qGo43yqQG8o6STJmK4zCi1kSJ
H262BJ+FR2Y=
=ZE6t
-END PGP SIGNATURE-


Accepted:
tiger-otheros_3.2.1-32_i386.deb
  to pool/main/t/tiger/tiger-otheros_3.2.1-32_i386.deb
tiger_3.2.1-32.diff.gz
  to pool/main/t/tiger/tiger_3.2.1-32.diff.gz
tiger_3.2.1-32.dsc
  to pool/main/t/tiger/tiger_3.2.1-32.dsc
tiger_3.2.1-32_i386.deb
  to pool/main/t/tiger/tiger_3.2.1-32_i386.deb


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



Accepted motor 2:3.4.0-7 (source all i386)

2006-08-30 Thread eloy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 14:12:37 +0200
Source: motor
Binary: motor motor-fribidi motor-common
Architecture: source all i386
Version: 2:3.4.0-7
Distribution: unstable
Urgency: low
Maintainer: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED]
Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED]
Description: 
 motor  - C/C++/Java Integrated Development Environment
 motor-common - C/C++/Java Integrated Development Environment
 motor-fribidi - C/C++/Java Integrated Development Environment
Closes: 384716
Changes: 
 motor (2:3.4.0-7) unstable; urgency=low
 .
   * Apply patch 01-cast for ppc64 as well (closes: #384716)
Files: 
 6395965e486a53618f38012befe8f0e7 736 editors optional motor_3.4.0-7.dsc
 c979de9b8e6f7766cf48e2f4ba46adb4 27326 editors optional motor_3.4.0-7.diff.gz
 f658fc65a67bbdc61024973880f91237 378640 editors optional 
motor-fribidi_3.4.0-7_i386.deb
 cec5cd147840e628824be25cf30e6824 378564 editors optional motor_3.4.0-7_i386.deb
 edcc0c99f488a5d3b2faf150f95c96e4 153776 editors optional 
motor-common_3.4.0-7_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9YTI+NMfSd6w7DERAlboAJ0U5JVed1owtxzJEPnC8mAfJcRuyQCfaucU
FWGKXcFKLxwjcf3cJSxkiHE=
=tnyC
-END PGP SIGNATURE-


Accepted:
motor-common_3.4.0-7_all.deb
  to pool/main/m/motor/motor-common_3.4.0-7_all.deb
motor-fribidi_3.4.0-7_i386.deb
  to pool/main/m/motor/motor-fribidi_3.4.0-7_i386.deb
motor_3.4.0-7.diff.gz
  to pool/main/m/motor/motor_3.4.0-7.diff.gz
motor_3.4.0-7.dsc
  to pool/main/m/motor/motor_3.4.0-7.dsc
motor_3.4.0-7_i386.deb
  to pool/main/m/motor/motor_3.4.0-7_i386.deb


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



Accepted lm-sensors 1:2.10.0-8 (source amd64)

2006-08-30 Thread Aurelien Jarno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 12:05:15 +0200
Source: lm-sensors
Binary: sensord libsensors-dev libsensors3 lm-sensors
Architecture: source amd64
Version: 1:2.10.0-8
Distribution: unstable
Urgency: medium
Maintainer: Aurelien Jarno [EMAIL PROTECTED]
Changed-By: Aurelien Jarno [EMAIL PROTECTED]
Description: 
 libsensors-dev - lm-sensors development kit
 libsensors3 - library to read temperature/voltage/fan sensors
 lm-sensors - utilities to read temperature/voltage/fan sensors
 sensord- hardware sensor information logging daemon
Closes: 372740 385279
Changes: 
 lm-sensors (1:2.10.0-8) unstable; urgency=medium
 .
   * 2.4 kernels are deprecated, stop building lm-sensors-source and
 kernel-patch-2.4-lm-sensors (Closes: bug#385279).
   * Disable lm85 /sys entries that while be introduced in 2.6.19+
 kernels (Closes: #372740).
Files: 
 a760e8bd242b57ad306fbe593ff93873 671 utils extra lm-sensors_2.10.0-8.dsc
 3e1190ed23d6013cb8dd0d8667e9d928 31779 utils extra lm-sensors_2.10.0-8.diff.gz
 26c2cdda0a2af4f2055f4ece4b9474de 489828 utils extra 
lm-sensors_2.10.0-8_amd64.deb
 d0bd3b627327bb8b3af7d2c1c005a269 93054 libs optional 
libsensors3_2.10.0-8_amd64.deb
 b2f31ef869778e4b24f17270584d263b 103250 libdevel extra 
libsensors-dev_2.10.0-8_amd64.deb
 f9bf3271f82e67242b6eb4c5c592e8b1 60630 utils extra sensord_2.10.0-8_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9YcAw3ao2vG823MRAqKaAJ4nvspZzcVopZn67KUhf//Zo75eagCeLHw0
sCq28LETMfWMiyoH0y7qYhg=
=Ewm7
-END PGP SIGNATURE-


Accepted:
libsensors-dev_2.10.0-8_amd64.deb
  to pool/main/l/lm-sensors/libsensors-dev_2.10.0-8_amd64.deb
libsensors3_2.10.0-8_amd64.deb
  to pool/main/l/lm-sensors/libsensors3_2.10.0-8_amd64.deb
lm-sensors_2.10.0-8.diff.gz
  to pool/main/l/lm-sensors/lm-sensors_2.10.0-8.diff.gz
lm-sensors_2.10.0-8.dsc
  to pool/main/l/lm-sensors/lm-sensors_2.10.0-8.dsc
lm-sensors_2.10.0-8_amd64.deb
  to pool/main/l/lm-sensors/lm-sensors_2.10.0-8_amd64.deb
sensord_2.10.0-8_amd64.deb
  to pool/main/l/lm-sensors/sensord_2.10.0-8_amd64.deb


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



Accepted maildrop 2.0.2-5 (source i386)

2006-08-30 Thread Josip Rodin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 14:06:05 +0200
Source: maildrop
Binary: maildrop
Architecture: source i386
Version: 2.0.2-5
Distribution: unstable
Urgency: low
Maintainer: Josip Rodin [EMAIL PROTECTED]
Changed-By: Josip Rodin [EMAIL PROTECTED]
Description: 
 maildrop   - mail delivery agent with filtering abilities
Closes: 228581 253092
Changes: 
 maildrop (2.0.2-5) unstable; urgency=low
 .
   * Noted documentation for the courier-authlib issue in the NEWS.Debian
 entry (it's described in INSTALL).
   * Updated the MTA explicit+pipe dependency to Exim 4, closes: #228581.
   * Added maildirquota manual page to the alternatives, due to conflict
 with courier-base, closes: #253092.
Files: 
 ceae2e9903472d943001a0bb71da621c 672 mail optional maildrop_2.0.2-5.dsc
 f201aee479af0c826ca8e6d6141d0707 9304 mail optional maildrop_2.0.2-5.diff.gz
 d9f13dbbb84d79950b4a27d6b3151c17 343884 mail optional maildrop_2.0.2-5_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFE9YLzC1RHoiANFZYRAoEcAJ4kRLjJ2fp177dM6jXWUyNNHgLUQACfS5X5
yJPVXIzgdqzWXDqCZxIaz4Y=
=Ia00
-END PGP SIGNATURE-


Accepted:
maildrop_2.0.2-5.diff.gz
  to pool/main/m/maildrop/maildrop_2.0.2-5.diff.gz
maildrop_2.0.2-5.dsc
  to pool/main/m/maildrop/maildrop_2.0.2-5.dsc
maildrop_2.0.2-5_i386.deb
  to pool/main/m/maildrop/maildrop_2.0.2-5_i386.deb


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



Accepted rt2400 1.2.2+cvs20060620-4 (source all amd64)

2006-08-30 Thread Aurelien Jarno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 14:49:18 +0200
Source: rt2400
Binary: rt2400-source rt2400
Architecture: source all amd64
Version: 1.2.2+cvs20060620-4
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno [EMAIL PROTECTED]
Changed-By: Aurelien Jarno [EMAIL PROTECTED]
Description: 
 rt2400 - configuration tool for wireless RT2400 network cards
 rt2400-source - RT2400 wireless network drivers source
Closes: 385205
Changes: 
 rt2400 (1.2.2+cvs20060620-4) unstable; urgency=low
 .
   * debian/rules: fix a bashims (closes: bug#385205).
Files: 
 242c6a5d13cef44a835364e5b2d369a2 728 net extra rt2400_1.2.2+cvs20060620-4.dsc
 1fb93d8e64305cef60b74e52b8872447 7448 net extra 
rt2400_1.2.2+cvs20060620-4.diff.gz
 f01cc88cc81999263f09cf135306b70e 173316 net extra 
rt2400-source_1.2.2+cvs20060620-4_all.deb
 11bb20abe70ea6c867e53c07af89937a 99410 net extra 
rt2400_1.2.2+cvs20060620-4_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9Yoqw3ao2vG823MRAv2+AJ9NRYFZe+BuvagpYLJOfESccfwvWgCdG5So
ZzXKFZuA+xCEneyJEg0q8dg=
=aRga
-END PGP SIGNATURE-


Accepted:
rt2400-source_1.2.2+cvs20060620-4_all.deb
  to pool/main/r/rt2400/rt2400-source_1.2.2+cvs20060620-4_all.deb
rt2400_1.2.2+cvs20060620-4.diff.gz
  to pool/main/r/rt2400/rt2400_1.2.2+cvs20060620-4.diff.gz
rt2400_1.2.2+cvs20060620-4.dsc
  to pool/main/r/rt2400/rt2400_1.2.2+cvs20060620-4.dsc
rt2400_1.2.2+cvs20060620-4_amd64.deb
  to pool/main/r/rt2400/rt2400_1.2.2+cvs20060620-4_amd64.deb


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



Accepted rt2570 1.1.0+cvs20060620-3 (source all)

2006-08-30 Thread Aurelien Jarno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 15:03:38 +0200
Source: rt2570
Binary: rt2570-source
Architecture: source all
Version: 1.1.0+cvs20060620-3
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno [EMAIL PROTECTED]
Changed-By: Aurelien Jarno [EMAIL PROTECTED]
Description: 
 rt2570-source - RT2570 wireless network drivers source
Closes: 385206
Changes: 
 rt2570 (1.1.0+cvs20060620-3) unstable; urgency=low
 .
   * debian/rules: fix a bashims (closes: bug#385206).
Files: 
 535d51165217de04ab627ec5961b238a 652 net extra rt2570_1.1.0+cvs20060620-3.dsc
 97fc50fcd59d4676fa4d893d134ddcb1 4681 net extra 
rt2570_1.1.0+cvs20060620-3.diff.gz
 e9576dfd5d40d4040c92df4080ab9460 252478 net extra 
rt2570-source_1.1.0+cvs20060620-3_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9Y0Rw3ao2vG823MRAs9QAJ0aCknW+mmoV1xqn8NojKxOYrGFPACeKool
WoaOdciOWGFhM8yKK+D5Zc0=
=ntKQ
-END PGP SIGNATURE-


Accepted:
rt2570-source_1.1.0+cvs20060620-3_all.deb
  to pool/main/r/rt2570/rt2570-source_1.1.0+cvs20060620-3_all.deb
rt2570_1.1.0+cvs20060620-3.diff.gz
  to pool/main/r/rt2570/rt2570_1.1.0+cvs20060620-3.diff.gz
rt2570_1.1.0+cvs20060620-3.dsc
  to pool/main/r/rt2570/rt2570_1.1.0+cvs20060620-3.dsc


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



Accepted rt2500 1.1.0+cvs20060620-3 (source all amd64)

2006-08-30 Thread Aurelien Jarno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 14:56:48 +0200
Source: rt2500
Binary: rt2500 rt2500-source
Architecture: source all amd64
Version: 1.1.0+cvs20060620-3
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno [EMAIL PROTECTED]
Changed-By: Aurelien Jarno [EMAIL PROTECTED]
Description: 
 rt2500 - configuration tool for wireless RT2500 network cards
 rt2500-source - RT2500 wireless network drivers source
Closes: 385207
Changes: 
 rt2500 (1.1.0+cvs20060620-3) unstable; urgency=low
 .
   * debian/rules: fix a bashism (closes: bug#385207).
Files: 
 abf258d6902871aa5a398f4c6354217f 729 net extra rt2500_1.1.0+cvs20060620-3.dsc
 76e848334ef0f7e77f5150a96b1f0b49 21703 net extra 
rt2500_1.1.0+cvs20060620-3.diff.gz
 fffc6d668c8528e68de0a17123d88b96 247554 net extra 
rt2500-source_1.1.0+cvs20060620-3_all.deb
 275d50decb0b742649470050588c7040 113504 net extra 
rt2500_1.1.0+cvs20060620-3_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9YvTw3ao2vG823MRAvTfAJ0YzwHRLh6piC1eH42dInMjW+LJOgCeN8Wn
9GDIyS2s8GLDBei9vtNrRqc=
=hsoX
-END PGP SIGNATURE-


Accepted:
rt2500-source_1.1.0+cvs20060620-3_all.deb
  to pool/main/r/rt2500/rt2500-source_1.1.0+cvs20060620-3_all.deb
rt2500_1.1.0+cvs20060620-3.diff.gz
  to pool/main/r/rt2500/rt2500_1.1.0+cvs20060620-3.diff.gz
rt2500_1.1.0+cvs20060620-3.dsc
  to pool/main/r/rt2500/rt2500_1.1.0+cvs20060620-3.dsc
rt2500_1.1.0+cvs20060620-3_amd64.deb
  to pool/main/r/rt2500/rt2500_1.1.0+cvs20060620-3_amd64.deb


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



Accepted linuxlogo 4.14-1 (source i386)

2006-08-30 Thread Khalid El Fathi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 29 Aug 2006 15:01:16 +0200
Source: linuxlogo
Binary: linuxlogo
Architecture: source i386
Version: 4.14-1
Distribution: unstable
Urgency: low
Maintainer: Khalid El Fathi [EMAIL PROTECTED]
Changed-By: Khalid El Fathi [EMAIL PROTECTED]
Description: 
 linuxlogo  - Color ANSI System Logo
Closes: 152191 384906
Changes: 
 linuxlogo (4.14-1) unstable; urgency=low
 .
   * New upstream release.
   * debian/watch: Added watch file.
   * Patch added Add lsb logging, thanks to David Hardeman [EMAIL PROTECTED]
 (Closes: #152191, #384906).
Files: 
 4f6308751dd4e0b0cd6d86c52b17fc98 579 misc extra linuxlogo_4.14-1.dsc
 5eeccebefff7416698dcbaebbb19cb87 91322 misc extra linuxlogo_4.14.orig.tar.gz
 3a452cf553e0588784c37d4db3b0b606 13945 misc extra linuxlogo_4.14-1.diff.gz
 8044075ba9ae659f65d475b415fd4791 62150 misc extra linuxlogo_4.14-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9ZQYw3ao2vG823MRAp3FAJ9Lp/DnNnOHmA9/bGRLiutYXcx5RwCeNVVN
9neoliOtjqOdrrIkR5kYRFs=
=Kogq
-END PGP SIGNATURE-


Accepted:
linuxlogo_4.14-1.diff.gz
  to pool/main/l/linuxlogo/linuxlogo_4.14-1.diff.gz
linuxlogo_4.14-1.dsc
  to pool/main/l/linuxlogo/linuxlogo_4.14-1.dsc
linuxlogo_4.14-1_i386.deb
  to pool/main/l/linuxlogo/linuxlogo_4.14-1_i386.deb
linuxlogo_4.14.orig.tar.gz
  to pool/main/l/linuxlogo/linuxlogo_4.14.orig.tar.gz


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



Accepted python-qt4 4.0.1-2 (source all i386)

2006-08-30 Thread Torsten Marek
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 14:54:59 +0200
Source: python-qt4
Binary: python-qt4-gl pyqt4-dev-tools python-qt4-dev python-qt4-doc 
python-qt4-sql python-qt4
Architecture: source all i386
Version: 4.0.1-2
Distribution: unstable
Urgency: low
Maintainer: Torsten Marek [EMAIL PROTECTED]
Changed-By: Torsten Marek [EMAIL PROTECTED]
Description: 
 pyqt4-dev-tools - Development tools for PyQt4
 python-qt4 - Python bindings for Qt4
 python-qt4-dev - Development files for PyQt4
 python-qt4-doc - Documentation and examples for PyQt4
 python-qt4-gl - Python bindings for Qt4's OpenGL module
 python-qt4-sql - Python bindings for Qt4's SQL module
Closes: 381432
Changes: 
 python-qt4 (4.0.1-2) unstable; urgency=low
 .
   * Surround imports in Qt.py with exception handlers
 (Closes: #381432)
Files: 
 ed27062bec98a017ea902ad54053c6d1 794 python optional python-qt4_4.0.1-2.dsc
 51adcc0b9c38d095011223e8b970bffc 5827 python optional 
python-qt4_4.0.1-2.diff.gz
 f7266a6122269a9d5b92f22c7cf7f142 3039916 python optional 
python-qt4_4.0.1-2_i386.deb
 262db61b43a0227fd6deac54c2c65104 107822 python optional 
python-qt4-gl_4.0.1-2_i386.deb
 1498c806e78fdde04199327c844f8f1e 194702 python optional 
python-qt4-sql_4.0.1-2_i386.deb
 1a1fbeffb3eb04fddc2bbac1ecd181ad 127410 python optional 
pyqt4-dev-tools_4.0.1-2_i386.deb
 cbed0785c3bb6cf2105bd86597d8b79f 194762 python optional 
python-qt4-dev_4.0.1-2_all.deb
 84534bd6e66e671050ab6cf2e098ace4 698138 doc optional 
python-qt4-doc_4.0.1-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9ZKifMVFHqJEyFgRArpoAJ4vniwO7WoMkTpA5twZ7lG3XsfTqgCgkaN9
C/GsflXBuSn1578P/SGZRdo=
=eaGG
-END PGP SIGNATURE-


Accepted:
pyqt4-dev-tools_4.0.1-2_i386.deb
  to pool/main/p/python-qt4/pyqt4-dev-tools_4.0.1-2_i386.deb
python-qt4-dev_4.0.1-2_all.deb
  to pool/main/p/python-qt4/python-qt4-dev_4.0.1-2_all.deb
python-qt4-doc_4.0.1-2_all.deb
  to pool/main/p/python-qt4/python-qt4-doc_4.0.1-2_all.deb
python-qt4-gl_4.0.1-2_i386.deb
  to pool/main/p/python-qt4/python-qt4-gl_4.0.1-2_i386.deb
python-qt4-sql_4.0.1-2_i386.deb
  to pool/main/p/python-qt4/python-qt4-sql_4.0.1-2_i386.deb
python-qt4_4.0.1-2.diff.gz
  to pool/main/p/python-qt4/python-qt4_4.0.1-2.diff.gz
python-qt4_4.0.1-2.dsc
  to pool/main/p/python-qt4/python-qt4_4.0.1-2.dsc
python-qt4_4.0.1-2_i386.deb
  to pool/main/p/python-qt4/python-qt4_4.0.1-2_i386.deb


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



Accepted markdown 1.0.2~b7-1 (source all)

2006-08-30 Thread Matt Kraai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 06:44:25 -0700
Source: markdown
Binary: markdown
Architecture: source all
Version: 1.0.2~b7-1
Distribution: experimental
Urgency: low
Maintainer: Matt Kraai [EMAIL PROTECTED]
Changed-By: Matt Kraai [EMAIL PROTECTED]
Description: 
 markdown   - Text-to-HTML conversion tool
Closes: 380212
Changes: 
 markdown (1.0.2~b7-1) experimental; urgency=low
 .
   * New beta release, closes: #380212.
Files: 
 c0d7741d8f438da38c4050fd842504bb 535 web optional markdown_1.0.2~b7-1.dsc
 3f1586ca4b9a6fc42fe7350a42f5d44e 18444 web optional 
markdown_1.0.2~b7.orig.tar.gz
 f58215c64878371d6e62554832d5e117 4048 web optional markdown_1.0.2~b7-1.diff.gz
 22807392dde5039c55478be1e8ec2a97 19190 web optional markdown_1.0.2~b7-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9Za1fNdgYxVXvBARAghyAJ9srVAKbBSUaUyjnyQmA8+WPOeWuQCfRV+/
bKIlnoInIsQ13f1UkI+HVlU=
=jzl7
-END PGP SIGNATURE-


Accepted:
markdown_1.0.2~b7-1.diff.gz
  to pool/main/m/markdown/markdown_1.0.2~b7-1.diff.gz
markdown_1.0.2~b7-1.dsc
  to pool/main/m/markdown/markdown_1.0.2~b7-1.dsc
markdown_1.0.2~b7-1_all.deb
  to pool/main/m/markdown/markdown_1.0.2~b7-1_all.deb
markdown_1.0.2~b7.orig.tar.gz
  to pool/main/m/markdown/markdown_1.0.2~b7.orig.tar.gz


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



Accepted rosegarden 1:1.2.4-1 (source all amd64)

2006-08-30 Thread Free Ekanayaka
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 14:33:00 +0200
Source: rosegarden
Binary: rosegarden2 rosegarden4 rosegarden-data rosegarden
Architecture: source all amd64
Version: 1:1.2.4-1
Distribution: unstable
Urgency: low
Maintainer: Debian Multimedia Team debian-multimedia@lists.debian.org
Changed-By: Free Ekanayaka [EMAIL PROTECTED]
Description: 
 rosegarden - music editor and MIDI/audio sequencer
 rosegarden-data - music editor and MIDI/audio sequencer data files
 rosegarden2 - music editor and MIDI/audio sequencer
 rosegarden4 - music editor and MIDI/audio sequencer
Closes: 374814
Changes: 
 rosegarden (1:1.2.4-1) unstable; urgency=low
 .
   [ Mike O'Connor ]
   * New upstream release (Closes: #374814)
   * Got rid of patches which have been applied upstream
   * Switched dependencies in control file to use ${Source-Version}
 .
   [ Free Ekanayaka ]
   * Upstream tarball name is changed, fixed watch file accordingly
Files: 
 c3bdaac98046e98a473af36ca2837612 892 sound optional rosegarden_1.2.4-1.dsc
 34ee1ecd103407b475b39c6e93b010e4 6185975 sound optional 
rosegarden_1.2.4.orig.tar.gz
 bb6ba8c439160d433191b873893ba3cb 12664 sound optional 
rosegarden_1.2.4-1.diff.gz
 3428d98de899fd30536fa213b58e2032 3412148 sound optional 
rosegarden_1.2.4-1_amd64.deb
 aecfdb440ac17b9fde3de32840c074a5 6220 sound optional 
rosegarden2_1.2.4-1_all.deb
 9cbc325afa4caa3a7f99220c248c5e39 6218 sound optional 
rosegarden4_1.2.4-1_all.deb
 f9ffb948c4a04de997d50ff471d83ba1 2147124 sound optional 
rosegarden-data_1.2.4-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFE9ZJwcanJGlcVnlkRAmcaAKDu5Tz9xruWM63M1QeUZVkv4UHQ5gCcD7m8
HodEQTQMPVrg0ps3DuI4MuA=
=QPo4
-END PGP SIGNATURE-


Accepted:
rosegarden-data_1.2.4-1_all.deb
  to pool/main/r/rosegarden/rosegarden-data_1.2.4-1_all.deb
rosegarden2_1.2.4-1_all.deb
  to pool/main/r/rosegarden/rosegarden2_1.2.4-1_all.deb
rosegarden4_1.2.4-1_all.deb
  to pool/main/r/rosegarden/rosegarden4_1.2.4-1_all.deb
rosegarden_1.2.4-1.diff.gz
  to pool/main/r/rosegarden/rosegarden_1.2.4-1.diff.gz
rosegarden_1.2.4-1.dsc
  to pool/main/r/rosegarden/rosegarden_1.2.4-1.dsc
rosegarden_1.2.4-1_amd64.deb
  to pool/main/r/rosegarden/rosegarden_1.2.4-1_amd64.deb
rosegarden_1.2.4.orig.tar.gz
  to pool/main/r/rosegarden/rosegarden_1.2.4.orig.tar.gz


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



Accepted geresh 0.6.3-7 (source i386)

2006-08-30 Thread Lior Kaplan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 17:32:53 +0300
Source: geresh
Binary: geresh
Architecture: source i386
Version: 0.6.3-7
Distribution: unstable
Urgency: low
Maintainer: Lior Kaplan [EMAIL PROTECTED]
Changed-By: Lior Kaplan [EMAIL PROTECTED]
Description: 
 geresh - A simple multilingual text editor with utf-8  bidi support
Closes: 363603
Changes: 
 geresh (0.6.3-7) unstable; urgency=low
 .
   * debian/control
 - Fix spelling mistake in package description (Closes: #363603)
 - Upgrade Standards-Version to 3.7.2 (no changes needed)
   * Add or any later version to debian/copyright
Files: 
 99d7f66fe901f881ed665d804038c818 589 editors optional geresh_0.6.3-7.dsc
 cb0082369e6db4a993cdc27ab90e8558 6904 editors optional geresh_0.6.3-7.diff.gz
 80b154634e1df78f27afcc5c1387ce0f 185624 editors optional 
geresh_0.6.3-7_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9aLwFViURZnoHaARAr3GAJ4gTyVXwgjZ4I+5BXvecNpCcmjowgCgnvPE
GtOKPUkLyAhKeN6mZaszwTI=
=QmRo
-END PGP SIGNATURE-


Accepted:
geresh_0.6.3-7.diff.gz
  to pool/main/g/geresh/geresh_0.6.3-7.diff.gz
geresh_0.6.3-7.dsc
  to pool/main/g/geresh/geresh_0.6.3-7.dsc
geresh_0.6.3-7_i386.deb
  to pool/main/g/geresh/geresh_0.6.3-7_i386.deb


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



Accepted localepurge 0.5.6 (source all)

2006-08-30 Thread Paul Seelig
-BEGIN PGP SIGNED MESSAGE-

Format: 1.7
Date: Wed, 30 Aug 2006 16:30:36 +0200
Source: localepurge
Binary: localepurge
Architecture: source all
Version: 0.5.6
Distribution: unstable
Urgency: low
Maintainer: Paul Seelig [EMAIL PROTECTED]
Changed-By: Paul Seelig [EMAIL PROTECTED]
Description: 
 localepurge - Automagically remove unnecessary locale data
Closes: 381585 384997
Changes: 
 localepurge (0.5.6) unstable; urgency=low
 .
   * Removed old versions of postinst/postrm files from debian subdir.
 .
   * debian/po/ja.po: Updated with new revision as supplied by Shimono
 Atsushi. Thank you! (closes: #384997)
 .
   * debian/localepurge.templates: Made deletion of localized man pages
 the default setting.
 .
   * debian/postrm: Update check for purge actions because config files
 were not removed anymore.
 .
   * debian/postrm: Corrected last sentence by adding the missing word 'of'.
 .
   * debian/postinst: Check for existence of $CONFIGFILE before chown'ing
 and chmod'ing it.
 .
   * debian/postinst: Make sure a valid $CONFIGFILE exists before applying ucf.
 .
   * debian/localepurge.config: To make sure it exists during very first
 installation of package, touch temp file $LOCALEGEN. (closes: #381585)
 .
   * usr/bin/localepurge: Move check for existence of configuration file
 to the very beginning of the script.
Files: 
 338f4c8e792b89d2b5e44ee08bf25e9d 613 admin optional localepurge_0.5.6.dsc
 d94b90a4acee1eb1b3400bbdcec0e415 36573 admin optional localepurge_0.5.6.tar.gz
 09ca4d1d59a09c97b28f84774e492f5e 35930 admin optional localepurge_0.5.6_all.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: latin1

iQCUAwUBRPWjZugqiw1XE3/lAQHM7wP4qH9FHFyL9VnqsLTrt+LpoQUUxgwuB/6c
rOCmKBTk2F1mWvaspvwOkNSy4XUe0A/Zn7FcZGWJs5RR3F9hWU4qtVSltyMpE7E9
yP7aeJ6NCokKLjbGYX+W/xyAn+3AvAu4vBYEgfd6B6PDtXMWrZWW1PIkVQ64haQB
rf8gmcslUg==
=qYnH
-END PGP SIGNATURE-


Accepted:
localepurge_0.5.6.dsc
  to pool/main/l/localepurge/localepurge_0.5.6.dsc
localepurge_0.5.6.tar.gz
  to pool/main/l/localepurge/localepurge_0.5.6.tar.gz
localepurge_0.5.6_all.deb
  to pool/main/l/localepurge/localepurge_0.5.6_all.deb


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



Accepted petris 1.0.1-6 (source amd64)

2006-08-30 Thread Andree Leidenfrost
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 31 Aug 2006 00:49:58 +1000
Source: petris
Binary: petris
Architecture: source amd64
Version: 1.0.1-6
Distribution: unstable
Urgency: low
Maintainer: Andree Leidenfrost [EMAIL PROTECTED]
Changed-By: Andree Leidenfrost [EMAIL PROTECTED]
Description: 
 petris - Peter's Tetris - a Tetris(TM) clone
Changes: 
 petris (1.0.1-6) unstable; urgency=low
 .
   * Changed maintainer email address to [EMAIL PROTECTED]
   * Changed standards version from 3.6.2 to 3.7.2 without package
 changes. (Fixes lintian warning.)
   * Increased package compatibility level to 5 and build-depend on
 debhelper = 5.0 accordingly.
   * Removed spurious debian/substvars file. (Fixes lintian warning.)
Files: 
 08fb83bb9e86a040b4c9aa27bfbf4e33 576 games optional petris_1.0.1-6.dsc
 ec677a7cc40c2224fe82c5e4352ecc4f 4694 games optional petris_1.0.1-6.diff.gz
 0fa0f04c758905aee53e5d859fa40679 16298 games optional petris_1.0.1-6_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9aXViLvX3b2IzawRAo4RAKC0Fn9wUWOC+BhFy07tJUhbSOqNjQCfaQ1E
EwDD5HpkonaTZ7FGOMl8RKQ=
=y2U5
-END PGP SIGNATURE-


Accepted:
petris_1.0.1-6.diff.gz
  to pool/main/p/petris/petris_1.0.1-6.diff.gz
petris_1.0.1-6.dsc
  to pool/main/p/petris/petris_1.0.1-6.dsc
petris_1.0.1-6_amd64.deb
  to pool/main/p/petris/petris_1.0.1-6_amd64.deb


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



Accepted grub 0.97-14 (source i386 all)

2006-08-30 Thread Otavio Salvador
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 12:24:48 -0300
Source: grub
Binary: grub-disk grub grub-doc
Architecture: source i386 all
Version: 0.97-14
Distribution: unstable
Urgency: low
Maintainer: Grub Maintainers [EMAIL PROTECTED]
Changed-By: Otavio Salvador [EMAIL PROTECTED]
Description: 
 grub   - GRand Unified Bootloader
 grub-disk  - GRUB bootable disk image
 grub-doc   - Documentation for GRand Unified Bootloader
Closes: 361929
Changes: 
 grub (0.97-14) unstable; urgency=low
 .
   [ Robert Millan ]
   * Make update-grub more $menu_file agnostic to ease code sharing with grub2
 (which uses grub.cfg).  Also remove explicit boot command that has never
 been required, and would break grub2.
   * Fix FHS-me-harder headache.  (Closes: #361929)
 - rules:  --prefix=/usr.
 - grub.install:  Move the stuff to /usr.
   * update-grub:  Set interpreter to /bin/bash to cope with non-POSIX
 extensions.  (also mentioned in #361929)
 .
   [ Otavio Salvador ]
   * Remove convert_kernel26 usage since it's not necessary anymore and due
 initramfs-tools changes it's bug too.
   * Add a NEWS file describing how to upgrade the system regarting to
 grub-install and update-grub moving.
   * Change the way we handle FHS headache:
 - debian/wrappers: New. Provide a wrapper to old locations.
- debian/rules: install the wrappers.
 - grub.dirs: New. Create /sbin.
Files: 
 d51e1a3bd47bab6c8bfd98ec1360a660 950 admin optional grub_0.97-14.dsc
 7aad903cf5905528787072973f02ddee 70627 admin optional grub_0.97-14.diff.gz
 53b125dd45df224d74b67a0067e58b22 370702 admin optional grub_0.97-14_i386.deb
 3f943953ccebad92b845f3aa30774f25 239418 admin optional 
grub-disk_0.97-14_all.deb
 05e621f0c05f908da3d485668a3c902a 270242 doc optional grub-doc_0.97-14_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9a54LqiZQEml+FURAu9rAKCiMLesXD4lrP5Z/EwPSbP0fQhRSACgtsn8
Cnw9v4rRv3W+qWl5hGprZw4=
=oDG6
-END PGP SIGNATURE-


Accepted:
grub-disk_0.97-14_all.deb
  to pool/main/g/grub/grub-disk_0.97-14_all.deb
grub-doc_0.97-14_all.deb
  to pool/main/g/grub/grub-doc_0.97-14_all.deb
grub_0.97-14.diff.gz
  to pool/main/g/grub/grub_0.97-14.diff.gz
grub_0.97-14.dsc
  to pool/main/g/grub/grub_0.97-14.dsc
grub_0.97-14_i386.deb
  to pool/main/g/grub/grub_0.97-14_i386.deb


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



Accepted dwm 1.2-1 (source i386)

2006-08-30 Thread Daniel Baumann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 20:01:00 +0200
Source: dwm
Binary: dwm
Architecture: source i386
Version: 1.2-1
Distribution: unstable
Urgency: low
Maintainer: Daniel Baumann [EMAIL PROTECTED]
Changed-By: Daniel Baumann [EMAIL PROTECTED]
Description: 
 dwm- dynamic window manager
Changes: 
 dwm (1.2-1) unstable; urgency=low
 .
   * New upstream release.
Files: 
 5fc3351c330d93398f4148419b568d9b 566 x11 optional dwm_1.2-1.dsc
 7a8e8728b2e5d5781021641b49261399 15829 x11 optional dwm_1.2.orig.tar.gz
 1d5b874d1f3c83fb7b73dc74439b3fe8 3447 x11 optional dwm_1.2-1.diff.gz
 ea458e6f828a0c3cec50354ced3b5dbd 18054 x11 optional dwm_1.2-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9dK4+C5cwEsrK54RAjdeAKCXKGzeTOSeg0+uHEmxCNQsij+S4wCbBYpz
inV+4nRziSKrJD2NtDohYEU=
=9awC
-END PGP SIGNATURE-


Accepted:
dwm_1.2-1.diff.gz
  to pool/main/d/dwm/dwm_1.2-1.diff.gz
dwm_1.2-1.dsc
  to pool/main/d/dwm/dwm_1.2-1.dsc
dwm_1.2-1_i386.deb
  to pool/main/d/dwm/dwm_1.2-1_i386.deb
dwm_1.2.orig.tar.gz
  to pool/main/d/dwm/dwm_1.2.orig.tar.gz


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



Accepted gcl 2.6.7-19 (source i386 all)

2006-08-30 Thread Camm Maguire
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 12:13:46 -0400
Source: gcl
Binary: gcl-doc gcl
Architecture: source i386 all
Version: 2.6.7-19
Distribution: unstable
Urgency: low
Maintainer: Camm Maguire [EMAIL PROTECTED]
Changed-By: Camm Maguire [EMAIL PROTECTED]
Description: 
 gcl- GNU Common Lisp compiler
 gcl-doc- Documentation for GNU Common Lisp
Closes: 376806 385126 385176
Changes: 
 gcl (2.6.7-19) unstable; urgency=low
 .
   * xgcl upgrade
   * parse_number from cvs head with *read-base* fixes
   * fix object_to_string
   * install xgcl-2/sysdef.lisp
   * fix info dir and emacs site lisp dir installation
   * New xgcl readme
   * Remove bashism from debian/rules, Closes: #376806, Closes: #385176.
   * Fix dwdoc doc-base error, Closes: #385126
Files: 
 46c87a3636575468cb0e29ddc9785a25 730 interpreters optional gcl_2.6.7-19.dsc
 7eab9ae87e72e895f7576ff547172219 14454630 interpreters optional 
gcl_2.6.7-19.diff.gz
 5cc18a8ca4cf56d9e6cad51ef40420a3 765938 doc optional gcl-doc_2.6.7-19_all.deb
 bf24989f8b3dda32e70d8c8e421f1173 28807156 interpreters optional 
gcl_2.6.7-19_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFE9ceBczG1wFfwRdwRAvaEAJ40WAXKYQqcTRG4yj7x2jG78xE6NgCcDQ+F
jZ1K8F8/Dozltoa05wVe5vQ=
=dntv
-END PGP SIGNATURE-


Accepted:
gcl-doc_2.6.7-19_all.deb
  to pool/main/g/gcl/gcl-doc_2.6.7-19_all.deb
gcl_2.6.7-19.diff.gz
  to pool/main/g/gcl/gcl_2.6.7-19.diff.gz
gcl_2.6.7-19.dsc
  to pool/main/g/gcl/gcl_2.6.7-19.dsc
gcl_2.6.7-19_i386.deb
  to pool/main/g/gcl/gcl_2.6.7-19_i386.deb


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



Accepted python-numarray 1.5.2-2 (source all i386)

2006-08-30 Thread Matthias Klose
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 17:52:29 +0200
Source: python-numarray
Binary: python-numarray python-numarray-doc python-numarray-ext
Architecture: source all i386
Version: 1.5.2-2
Distribution: unstable
Urgency: low
Maintainer: Matthias Klose [EMAIL PROTECTED]
Changed-By: Matthias Klose [EMAIL PROTECTED]
Description: 
 python-numarray - An array processing package modelled after Python-Numeric
 python-numarray-doc - An array processing package for Python (documentation)
 python-numarray-ext - Extension modules for Python array processing
Closes: 372487 372947 385330
Changes: 
 python-numarray (1.5.2-2) unstable; urgency=low
 .
   * Re-apply lost changes from 1.5.1-3 and 1.5.1-4.
 Closes: #372487, #372947, #385330.
Files: 
 a672559ec0850be93d013b292173c336 818 python optional 
python-numarray_1.5.2-2.dsc
 827e2a5842f7a33502645aa9ab81b9c6 6507 python optional 
python-numarray_1.5.2-2.diff.gz
 36cdc2bdecc17ff91a0cde8e5fe63f41 946168 python optional 
python-numarray_1.5.2-2_i386.deb
 763d972543c006dfdba91edf9429c593 289458 python optional 
python-numarray-ext_1.5.2-2_i386.deb
 8592d1d37ff619131a5e6b80b9a3ce55 291530 doc optional 
python-numarray-doc_1.5.2-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9baKStlRaw+TLJwRAla8AJ9+PQM5Fq7thfjomwzKB6YYXKOZUACgoS8+
o7OpCMSEJsLLR2wl41+Ph9Y=
=LTC+
-END PGP SIGNATURE-


Accepted:
python-numarray-doc_1.5.2-2_all.deb
  to pool/main/p/python-numarray/python-numarray-doc_1.5.2-2_all.deb
python-numarray-ext_1.5.2-2_i386.deb
  to pool/main/p/python-numarray/python-numarray-ext_1.5.2-2_i386.deb
python-numarray_1.5.2-2.diff.gz
  to pool/main/p/python-numarray/python-numarray_1.5.2-2.diff.gz
python-numarray_1.5.2-2.dsc
  to pool/main/p/python-numarray/python-numarray_1.5.2-2.dsc
python-numarray_1.5.2-2_i386.deb
  to pool/main/p/python-numarray/python-numarray_1.5.2-2_i386.deb


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



Accepted vdr-plugin-osdteletext 0.5.1-17 (source i386)

2006-08-30 Thread Thomas Schmidt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 28 Aug 2006 20:58:45 +0200
Source: vdr-plugin-osdteletext
Binary: vdr-plugin-osdteletext
Architecture: source i386
Version: 0.5.1-17
Distribution: unstable
Urgency: low
Maintainer: Debian VDR Team [EMAIL PROTECTED]
Changed-By: Thomas Schmidt [EMAIL PROTECTED]
Description: 
 vdr-plugin-osdteletext - Teletext plugin for vdr
Changes: 
 vdr-plugin-osdteletext (0.5.1-17) unstable; urgency=low
 .
   * Bumped Standards-Version to 3.7.2
   * Added note about the Debian Maintainers to debian/copyright
   * Build-Depend on vdr-dev (=1.4.2-1)
 .
 vdr-plugin-osdteletext (0.5.1-16) unstable; urgency=low
 .
   * Thomas Schmidt [EMAIL PROTECTED]
 - Build-Depend on vdr-dev (=1.4.1-1)
Files: 
 a3a542dbe383e3b4e2d5b5fb74307c1c 768 misc extra 
vdr-plugin-osdteletext_0.5.1-17.dsc
 c8544f6d990efd0924d4ea5c4978db8e 5680 misc extra 
vdr-plugin-osdteletext_0.5.1-17.diff.gz
 32b50e285a3eeaf8904163104b045802 56230 misc extra 
vdr-plugin-osdteletext_0.5.1-17_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9GSfc9+NqwoydlIRAk9sAKCZtkaUS7vupr5/Hi5MBP0bGlE0/wCgtzAh
6JzKGYmuYgmSk5m45oW/RnQ=
=afBC
-END PGP SIGNATURE-


Accepted:
vdr-plugin-osdteletext_0.5.1-17.diff.gz
  to pool/main/v/vdr-plugin-osdteletext/vdr-plugin-osdteletext_0.5.1-17.diff.gz
vdr-plugin-osdteletext_0.5.1-17.dsc
  to pool/main/v/vdr-plugin-osdteletext/vdr-plugin-osdteletext_0.5.1-17.dsc
vdr-plugin-osdteletext_0.5.1-17_i386.deb
  to pool/main/v/vdr-plugin-osdteletext/vdr-plugin-osdteletext_0.5.1-17_i386.deb


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



Accepted gphpedit 0.9.91-2 (source i386)

2006-08-30 Thread Lior Kaplan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 17:49:20 +0300
Source: gphpedit
Binary: gphpedit
Architecture: source i386
Version: 0.9.91-2
Distribution: unstable
Urgency: low
Maintainer: Lior Kaplan [EMAIL PROTECTED]
Changed-By: Lior Kaplan [EMAIL PROTECTED]
Description: 
 gphpedit   - development environment for PHP/HTML/CSS
Changes: 
 gphpedit (0.9.91-2) unstable; urgency=low
 .
   * Really add a watch file
Files: 
 d2b27def322bbd5f1afdbfe60616b8a7 621 gnome optional gphpedit_0.9.91-2.dsc
 906f6d2bc4330588be737015681ba3bb 13141 gnome optional gphpedit_0.9.91-2.diff.gz
 612a658a732f444c042d4b7f90b95058 443230 gnome optional 
gphpedit_0.9.91-2_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9acaFViURZnoHaARAjlgAJ9g6MHBNV7r9pvcEomOUZXn1o2hDACgl/WD
Q7DgKZvHaVKTYP19fuxIZyk=
=xoeB
-END PGP SIGNATURE-


Accepted:
gphpedit_0.9.91-2.diff.gz
  to pool/main/g/gphpedit/gphpedit_0.9.91-2.diff.gz
gphpedit_0.9.91-2.dsc
  to pool/main/g/gphpedit/gphpedit_0.9.91-2.dsc
gphpedit_0.9.91-2_i386.deb
  to pool/main/g/gphpedit/gphpedit_0.9.91-2_i386.deb


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



Accepted gedit 2.14.4-1 (source i386 all)

2006-08-30 Thread Loic Minier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 17:16:10 +0200
Source: gedit
Binary: gedit-dev gedit-common gedit
Architecture: source i386 all
Version: 2.14.4-1
Distribution: unstable
Urgency: low
Maintainer: Debian GNOME Maintainers [EMAIL PROTECTED]
Changed-By: Loic Minier [EMAIL PROTECTED]
Description: 
 gedit  - light-weight text editor
 gedit-common - light-weight text editor support files
 gedit-dev  - light-weight text editor
Changes: 
 gedit (2.14.4-1) unstable; urgency=low
 .
   * New upstream release; no API changes.
 - Relibtoolize.
   * Fix watch file.
   * Drop obsolete build-deps on libbonoboui2-dev, libeel2-dev, and libpopt-dev
 thanks Daniel Holbach.
   * Drop obsolete dep on libeel2-dev of gedit-dev, thanks Daniel Holbach.
   * Set Maintainer to the Debian GNOME team.
   * Bump up Standards-Version to 3.7.2.
Files: 
 cc114df9f14a322eb8aa5c3025b122e9 1676 gnome optional gedit_2.14.4-1.dsc
 49ae50e7421e816c2d106ec44ee34631 4105671 gnome optional 
gedit_2.14.4.orig.tar.gz
 7a9d15a4c56d75453eac0fcca584f018 161380 gnome optional gedit_2.14.4-1.diff.gz
 69e449875ad2532ee4b071d4ce48bd55 2833200 gnome optional 
gedit-common_2.14.4-1_all.deb
 536b8a0663030a1fffb3fa7ad094ae50 47300 devel optional 
gedit-dev_2.14.4-1_all.deb
 0a76b85f3529bb5dc69adf3b397cc403 553652 gnome optional gedit_2.14.4-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9bSz4VUX8isJIMARAlOpAJ4qPyD/y2vLSF30/NJmavDe2glYxACgtHDD
tf9iCw6LxPPXfDMO1T94EDM=
=zoDU
-END PGP SIGNATURE-


Accepted:
gedit-common_2.14.4-1_all.deb
  to pool/main/g/gedit/gedit-common_2.14.4-1_all.deb
gedit-dev_2.14.4-1_all.deb
  to pool/main/g/gedit/gedit-dev_2.14.4-1_all.deb
gedit_2.14.4-1.diff.gz
  to pool/main/g/gedit/gedit_2.14.4-1.diff.gz
gedit_2.14.4-1.dsc
  to pool/main/g/gedit/gedit_2.14.4-1.dsc
gedit_2.14.4-1_i386.deb
  to pool/main/g/gedit/gedit_2.14.4-1_i386.deb
gedit_2.14.4.orig.tar.gz
  to pool/main/g/gedit/gedit_2.14.4.orig.tar.gz


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



Accepted praat 4.4.30-1 (source i386)

2006-08-30 Thread Rafael Laboissiere
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 18:17:05 +0200
Source: praat
Binary: praat
Architecture: source i386
Version: 4.4.30-1
Distribution: unstable
Urgency: low
Maintainer: Rafael Laboissiere [EMAIL PROTECTED]
Changed-By: Rafael Laboissiere [EMAIL PROTECTED]
Description: 
 praat  - program for speech analysis and synthesis
Changes: 
 praat (4.4.30-1) unstable; urgency=low
 .
   * New upstream release
   * debian/praat.desktop: Desktop file for Praat (thanks to Hobbsee
 hobbsee at kubuntu dot org)
Files: 
 8d350b2996d2717ae0d80b2dd121577e 676 science optional praat_4.4.30-1.dsc
 bed13873d4b37b797815c9c0d51b2336 2519198 science optional 
praat_4.4.30.orig.tar.gz
 61471bc14b372c003ac7d30520eab99d 20545 science optional praat_4.4.30-1.diff.gz
 64b70fb596ee5e02e11934cbd507ee39 1551152 science optional 
praat_4.4.30-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFE9b+fk3oga0pdcv4RAuEEAJ99zYzsctSHdmky4ByeHLlH2vzaGwCdGPXP
HLBR0gP4vo6ddiDggDh7xwU=
=W+hG
-END PGP SIGNATURE-


Accepted:
praat_4.4.30-1.diff.gz
  to pool/main/p/praat/praat_4.4.30-1.diff.gz
praat_4.4.30-1.dsc
  to pool/main/p/praat/praat_4.4.30-1.dsc
praat_4.4.30-1_i386.deb
  to pool/main/p/praat/praat_4.4.30-1_i386.deb
praat_4.4.30.orig.tar.gz
  to pool/main/p/praat/praat_4.4.30.orig.tar.gz


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



Accepted python-stdlib-extensions 2.4.3-4 (source i386)

2006-08-30 Thread Matthias Klose
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 16:42:16 +
Source: python-stdlib-extensions
Binary: python-gdbm python-tk
Architecture: source i386
Version: 2.4.3-4
Distribution: unstable
Urgency: low
Maintainer: Matthias Klose [EMAIL PROTECTED]
Changed-By: Matthias Klose [EMAIL PROTECTED]
Description: 
 python-gdbm - GNU dbm database support for Python
 python-tk  - Tkinter - Writing Tk applications with Python
Changes: 
 python-stdlib-extensions (2.4.3-4) unstable; urgency=low
 .
   * Update 2.5 extensions, taken from the 2.5c1 release.
Files: 
 4dc73fe94e33afdc721a002db0605d57 836 python optional 
python-stdlib-extensions_2.4.3-4.dsc
 e050368c991153ae08ec6c056224adfa 105802 python optional 
python-stdlib-extensions_2.4.3.orig.tar.gz
 a3dc66dc8b58b1ab2c0f856f27f341d3 6610 python optional 
python-stdlib-extensions_2.4.3-4.diff.gz
 87a4122c7ff5e16ba0ecd2bb23a2e75f 59542 python optional 
python-tk_2.4.3-4_i386.deb
 d488015517606fac17a6e0e3b2405a06 14358 python optional 
python-gdbm_2.4.3-4_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9cNIStlRaw+TLJwRArZzAJsG8MhcRkjVzWB9aJr5Sxj6t+Q8+ACgrlOJ
3IfS4xMlD9B6xr+r6fg1Os0=
=vLuO
-END PGP SIGNATURE-


Accepted:
python-gdbm_2.4.3-4_i386.deb
  to pool/main/p/python-stdlib-extensions/python-gdbm_2.4.3-4_i386.deb
python-stdlib-extensions_2.4.3-4.diff.gz
  to 
pool/main/p/python-stdlib-extensions/python-stdlib-extensions_2.4.3-4.diff.gz
python-stdlib-extensions_2.4.3-4.dsc
  to pool/main/p/python-stdlib-extensions/python-stdlib-extensions_2.4.3-4.dsc
python-stdlib-extensions_2.4.3.orig.tar.gz
  to 
pool/main/p/python-stdlib-extensions/python-stdlib-extensions_2.4.3.orig.tar.gz
python-tk_2.4.3-4_i386.deb
  to pool/main/p/python-stdlib-extensions/python-tk_2.4.3-4_i386.deb


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



Accepted ffmpeg 0.cvs20060823-2 (source i386)

2006-08-30 Thread Debian packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 18:36:52 +0200
Source: ffmpeg
Binary: libavformat-dev libavformat0d ffmpeg libavcodec-dev libpostproc0d 
libpostproc-dev libavcodec0d
Architecture: source i386
Version: 0.cvs20060823-2
Distribution: unstable
Urgency: low
Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Description: 
 ffmpeg - multimedia player, server and encoder
 libavcodec-dev - development files for libavcodec
 libavcodec0d - ffmpeg codec library
 libavformat-dev - development files for libavformat
 libavformat0d - ffmpeg file format library
 libpostproc-dev - development files for libpostproc
 libpostproc0d - ffmpeg video postprocessing library
Changes: 
 ffmpeg (0.cvs20060823-2) unstable; urgency=low
 .
   * debian/patches/020_really_use_liba52.diff:
 + New patch: link with the shared liba52 instead of the built-in one.
 .
   * debian/patches/006_mips_pthreads.diff:
 + New patch: link libraries with -lpthreads on Linux MIPS because of a
   known ld bug.
 .
   * debian/patches/007_disable_ffmpeg_option.diff:
 + New patch: add a --disable-ffmpeg option.
Files: 
 1a008301cc2b01d1d037c7da692a62d5 986 libs optional ffmpeg_0.cvs20060823-2.dsc
 3109d66d542b12de526f19df50b0be82 16152 libs optional 
ffmpeg_0.cvs20060823-2.diff.gz
 d652448d0ea993caa2ce80a34c7e2c82 180712 graphics optional 
ffmpeg_0.cvs20060823-2_i386.deb
 0f120a5a59991dc9dbc1881990842b94 1525692 libs optional 
libavcodec0d_0.cvs20060823-2_i386.deb
 0987f8d1f9f1dc003b63c94766048abf 35396 libs optional 
libpostproc0d_0.cvs20060823-2_i386.deb
 6e2f04a200ebc8a637dc810174df4117 283722 libs optional 
libavformat0d_0.cvs20060823-2_i386.deb
 62419b92f63796931806afd0725b9fce 1582238 libdevel optional 
libavcodec-dev_0.cvs20060823-2_i386.deb
 8160620b29b3b36d8a55938a180df93f 35416 libdevel optional 
libpostproc-dev_0.cvs20060823-2_i386.deb
 3fa93c92b7526863f74351bfed81f5cb 327174 libdevel optional 
libavformat-dev_0.cvs20060823-2_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9cS7fPP1rylJn2ERAhrCAJ9eRWXGCP3N9pUrabjnshBnBGRoJACgji0P
wf0Qy1VnJ2RGcwaWj7QKrfA=
=1o6p
-END PGP SIGNATURE-


Accepted:
ffmpeg_0.cvs20060823-2.diff.gz
  to pool/main/f/ffmpeg/ffmpeg_0.cvs20060823-2.diff.gz
ffmpeg_0.cvs20060823-2.dsc
  to pool/main/f/ffmpeg/ffmpeg_0.cvs20060823-2.dsc
ffmpeg_0.cvs20060823-2_i386.deb
  to pool/main/f/ffmpeg/ffmpeg_0.cvs20060823-2_i386.deb
libavcodec-dev_0.cvs20060823-2_i386.deb
  to pool/main/f/ffmpeg/libavcodec-dev_0.cvs20060823-2_i386.deb
libavcodec0d_0.cvs20060823-2_i386.deb
  to pool/main/f/ffmpeg/libavcodec0d_0.cvs20060823-2_i386.deb
libavformat-dev_0.cvs20060823-2_i386.deb
  to pool/main/f/ffmpeg/libavformat-dev_0.cvs20060823-2_i386.deb
libavformat0d_0.cvs20060823-2_i386.deb
  to pool/main/f/ffmpeg/libavformat0d_0.cvs20060823-2_i386.deb
libpostproc-dev_0.cvs20060823-2_i386.deb
  to pool/main/f/ffmpeg/libpostproc-dev_0.cvs20060823-2_i386.deb
libpostproc0d_0.cvs20060823-2_i386.deb
  to pool/main/f/ffmpeg/libpostproc0d_0.cvs20060823-2_i386.deb


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



Accepted gnome-tasksel 0.9.8~pre1 (source all)

2006-08-30 Thread Gustavo Franco
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 11:09:10 -0300
Source: gnome-tasksel
Binary: gnome-tasksel
Architecture: source all
Version: 0.9.8~pre1
Distribution: unstable
Urgency: low
Maintainer: Gustavo Franco [EMAIL PROTECTED]
Changed-By: Gustavo Franco [EMAIL PROTECTED]
Description: 
 gnome-tasksel - GNOME interface to Debian tasks
Closes: 368518 379038
Changes: 
 gnome-tasksel (0.9.8~pre1) unstable; urgency=low
 .
   * New maintainer release. (Closes: #379038)
   * Add debian/patches/01_stratus-pre0.9.8.dpatch containing my upstream
 changes (pygtk2 transition and zvt to vte). (Closes: #368518)
 * debian/control:
 - Bump up debhelper compatibility to 5.
 - Add Build-Depends on dpatch.
 - Add Build-Depends-Indep on python.
 - Update Depends field adding ${python:Depends} and changing obsolete
   gtk1 deps to the new ones.
   * debian/rules: Add dh_python call to substitute ${python:Depends}.
   * debian/pycompat: Add and set to 1 (due to the dh_python call).
Files: 
 a4424c06ab57f895ccea84d803ff1405 585 gnome optional 
gnome-tasksel_0.9.8~pre1.dsc
 36270061f5b04ad851247742f43d2387 24784 gnome optional 
gnome-tasksel_0.9.8~pre1.tar.gz
 9aa92cffa45c18132d320a3c830abcd4 12418 gnome optional 
gnome-tasksel_0.9.8~pre1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9cSI7ftwBTcVV3gRAsNxAJ9B6yq4YPe97V5hKihG9ZpM2Mag/wCeOY5Z
EO3inKQHkfKGCIIyo7UpPdU=
=DwdG
-END PGP SIGNATURE-


Accepted:
gnome-tasksel_0.9.8~pre1.dsc
  to pool/main/g/gnome-tasksel/gnome-tasksel_0.9.8~pre1.dsc
gnome-tasksel_0.9.8~pre1.tar.gz
  to pool/main/g/gnome-tasksel/gnome-tasksel_0.9.8~pre1.tar.gz
gnome-tasksel_0.9.8~pre1_all.deb
  to pool/main/g/gnome-tasksel/gnome-tasksel_0.9.8~pre1_all.deb


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



Accepted zaptel 1:1.2.8.dfsg-1 (source all i386)

2006-08-30 Thread Mark Purcell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 23 Aug 2006 07:30:22 +0100
Source: zaptel
Binary: libtonezone1 zaptel-source zaptel libtonezone-dev
Architecture: source all i386
Version: 1:1.2.8.dfsg-1
Distribution: unstable
Urgency: low
Maintainer: Debian VoIP Team [EMAIL PROTECTED]
Changed-By: Mark Purcell [EMAIL PROTECTED]
Description: 
 libtonezone-dev - tonezone library (development)
 libtonezone1 - tonezone library (runtime)
 zaptel - zapata telephony utilities
 zaptel-source - Zapata telephony interface (source code for kernel driver)
Changes: 
 zaptel (1:1.2.8.dfsg-1) unstable; urgency=low
 .
   * New Upstream Release
Files: 
 ff06b3d44fa335dfe08f6b20319e31c8 957 comm optional zaptel_1.2.8.dfsg-1.dsc
 c85feb2b424a027d15d0a05278295581 908743 comm optional 
zaptel_1.2.8.dfsg.orig.tar.gz
 30b0f24e10173024f93fc46e55d63b1d 139203 comm optional 
zaptel_1.2.8.dfsg-1.diff.gz
 19dd0a61333199f0c3bab8e29a2d5ae6 672320 devel optional 
zaptel-source_1.2.8.dfsg-1_all.deb
 705bc49956256334756f4c619f72a831 101696 comm optional 
zaptel_1.2.8.dfsg-1_i386.deb
 fec3ebe072b3dc510e81d32a816d427d 24002 libs optional 
libtonezone1_1.2.8.dfsg-1_i386.deb
 054d23600b6d2ad072bfc3e4f74fe161 25020 libdevel optional 
libtonezone-dev_1.2.8.dfsg-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9SizoCzanz0IthIRAmzHAJ9zXmkybEM3y1c9bK9xUTQeQU3w0gCePAM9
//VABPwtngl+HvoswYq7Ens=
=yG3+
-END PGP SIGNATURE-


Accepted:
libtonezone-dev_1.2.8.dfsg-1_i386.deb
  to pool/main/z/zaptel/libtonezone-dev_1.2.8.dfsg-1_i386.deb
libtonezone1_1.2.8.dfsg-1_i386.deb
  to pool/main/z/zaptel/libtonezone1_1.2.8.dfsg-1_i386.deb
zaptel-source_1.2.8.dfsg-1_all.deb
  to pool/main/z/zaptel/zaptel-source_1.2.8.dfsg-1_all.deb
zaptel_1.2.8.dfsg-1.diff.gz
  to pool/main/z/zaptel/zaptel_1.2.8.dfsg-1.diff.gz
zaptel_1.2.8.dfsg-1.dsc
  to pool/main/z/zaptel/zaptel_1.2.8.dfsg-1.dsc
zaptel_1.2.8.dfsg-1_i386.deb
  to pool/main/z/zaptel/zaptel_1.2.8.dfsg-1_i386.deb
zaptel_1.2.8.dfsg.orig.tar.gz
  to pool/main/z/zaptel/zaptel_1.2.8.dfsg.orig.tar.gz


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



Accepted glib2.0 2.12.3-1 (source i386 all)

2006-08-30 Thread Loic Minier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 22:12:02 +0200
Source: glib2.0
Binary: libglib2.0-0-dbg libglib2.0-udeb libglib2.0-data libglib2.0-dev 
libglib2.0-doc libglib2.0-0
Architecture: source i386 all
Version: 2.12.3-1
Distribution: experimental
Urgency: low
Maintainer: Sebastien Bacher [EMAIL PROTECTED]
Changed-By: Loic Minier [EMAIL PROTECTED]
Description: 
 libglib2.0-0 - The GLib library of C routines
 libglib2.0-0-dbg - The GLib libraries and debugging symbols
 libglib2.0-data - Common files for GLib library
 libglib2.0-dev - Development files for the GLib library
 libglib2.0-doc - Documentation files for the GLib library
 libglib2.0-udeb - The GLib library of C routines (udeb)
Changes: 
 glib2.0 (2.12.3-1) experimental; urgency=low
 .
   * New upstream release; no public API changes.
   * Broaden the -data dep on the lib to permit bin NMUs.
Files: 
 9ef82801cd4bab74664697ff5c015cb8 1444 libs optional glib2.0_2.12.3-1.dsc
 e2b46451425dfa61f0c3ce76015bfc6a 3824526 libs optional 
glib2.0_2.12.3.orig.tar.gz
 af9b15becbe72fafe4b3fbb6340f3eed 17006 libs optional glib2.0_2.12.3-1.diff.gz
 37b3351bf1ec641b092d601a804797b8 271318 misc optional 
libglib2.0-data_2.12.3-1_all.deb
 4ee439a9842947d1339cd6d5307ebbb9 717774 doc optional 
libglib2.0-doc_2.12.3-1_all.deb
 9f6cca65a59cb9a2ed61aec15ce2e24d 503756 libs optional 
libglib2.0-0_2.12.3-1_i386.deb
 bf0362fabc74f37bf9b1dd3b63c1cdf7 599680 debian-installer optional 
libglib2.0-udeb_2.12.3-1_i386.udeb
 6749a8be2e4257da3d791fd20313b9fe 539834 libdevel optional 
libglib2.0-dev_2.12.3-1_i386.deb
 1b3be959fda0fc4472d565f84d4943aa 572950 libdevel extra 
libglib2.0-0-dbg_2.12.3-1_i386.deb
Package-Type: udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9fJc4VUX8isJIMARAloaAKCMzZEd45qP7SWRIDugmKItbnw5IgCcDH5Y
mT5yzdS+h+7i6KDsOW185+A=
=1iXA
-END PGP SIGNATURE-


Accepted:
glib2.0_2.12.3-1.diff.gz
  to pool/main/g/glib2.0/glib2.0_2.12.3-1.diff.gz
glib2.0_2.12.3-1.dsc
  to pool/main/g/glib2.0/glib2.0_2.12.3-1.dsc
glib2.0_2.12.3.orig.tar.gz
  to pool/main/g/glib2.0/glib2.0_2.12.3.orig.tar.gz
libglib2.0-0-dbg_2.12.3-1_i386.deb
  to pool/main/g/glib2.0/libglib2.0-0-dbg_2.12.3-1_i386.deb
libglib2.0-0_2.12.3-1_i386.deb
  to pool/main/g/glib2.0/libglib2.0-0_2.12.3-1_i386.deb
libglib2.0-data_2.12.3-1_all.deb
  to pool/main/g/glib2.0/libglib2.0-data_2.12.3-1_all.deb
libglib2.0-dev_2.12.3-1_i386.deb
  to pool/main/g/glib2.0/libglib2.0-dev_2.12.3-1_i386.deb
libglib2.0-doc_2.12.3-1_all.deb
  to pool/main/g/glib2.0/libglib2.0-doc_2.12.3-1_all.deb
libglib2.0-udeb_2.12.3-1_i386.udeb
  to pool/main/g/glib2.0/libglib2.0-udeb_2.12.3-1_i386.udeb


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



Accepted qgit 1.4-1 (source i386)

2006-08-30 Thread Wartan Hachaturow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 30 Aug 2006 22:39:49 +0400
Source: qgit
Binary: qgit
Architecture: source i386
Version: 1.4-1
Distribution: unstable
Urgency: low
Maintainer: Wartan Hachaturow [EMAIL PROTECTED]
Changed-By: Wartan Hachaturow [EMAIL PROTECTED]
Description: 
 qgit   - Qt application for viewing GIT trees
Closes: 373640
Changes: 
 qgit (1.4-1) unstable; urgency=low
 .
   * New upstream release
   * Minor package description improvement, Closes: #373640
Files: 
 ad3a03367decb7f1abbb5fea22dc52bb 594 x11 optional qgit_1.4-1.dsc
 198fe28c5e3c2ab6c76141499614bed1 232422 x11 optional qgit_1.4.orig.tar.gz
 c55aa669a80c1125099a511aad4e115e 25745 x11 optional qgit_1.4-1.diff.gz
 f42c84df02b39d06549454c0434278a7 394408 x11 optional qgit_1.4-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9fFauMozHxByYXERAh+3AJ9/YtDt/xkGDbPu4EDQOJ3O/khRKwCgsIkN
pdKvELrY9AU1bVv9x7v2CG8=
=8C4U
-END PGP SIGNATURE-


Accepted:
qgit_1.4-1.diff.gz
  to pool/main/q/qgit/qgit_1.4-1.diff.gz
qgit_1.4-1.dsc
  to pool/main/q/qgit/qgit_1.4-1.dsc
qgit_1.4-1_i386.deb
  to pool/main/q/qgit/qgit_1.4-1_i386.deb
qgit_1.4.orig.tar.gz
  to pool/main/q/qgit/qgit_1.4.orig.tar.gz


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



Accepted drscheme 1:352-4 (source amd64)

2006-08-30 Thread Ari Pollak
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Format: 1.7
Date: Mon, 28 Aug 2006 01:25:33 -0400
Source: drscheme
Binary: drscheme mzscheme
Architecture: source amd64
Version: 1:352-4
Distribution: unstable
Urgency: low
Maintainer: Ari Pollak [EMAIL PROTECTED]
Changed-By: Ari Pollak [EMAIL PROTECTED]
Description: 
 drscheme   - PLT Scheme Programming Environment
 mzscheme   - PLT Scheme Interpreter
Changes: 
 drscheme (1:352-4) unstable; urgency=low
 .
   * Fix a forgotten semicolon in 06_stack-direction-fix.patch.
   * Remove an outdated lintian override for readline, since we no longer ship
 it.
Files: 
 58bb7b990ac7af64128066543d8d1965 894 interpreters optional drscheme_352-4.dsc
 32a87e560a10a61caac24caed91dfc38 24036 interpreters optional 
drscheme_352-4.diff.gz
 e502888397c34d57e4752e273ec62036 11769684 interpreters optional 
drscheme_352-4_amd64.deb
 6d7caf251fc0cfa62ddc2dd545c87965 5198348 interpreters optional 
mzscheme_352-4_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFE9fRVwO+u47cOQDsRA/7jAJ4uYFYtdKXokSVrKJjzZdmEgY8xowCfewr4
cLEqe738NTQEKRYYZqai5JU=
=rNmr
-END PGP SIGNATURE-


Accepted:
drscheme_352-4.diff.gz
  to pool/main/d/drscheme/drscheme_352-4.diff.gz
drscheme_352-4.dsc
  to pool/main/d/drscheme/drscheme_352-4.dsc
drscheme_352-4_amd64.deb
  to pool/main/d/drscheme/drscheme_352-4_amd64.deb
mzscheme_352-4_amd64.deb
  to pool/main/d/drscheme/mzscheme_352-4_amd64.deb


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



  1   2   >