date:20031002

On Thu, Oct 02, 2003 at 05:57:58AM +0100, Scott James Remnant wrote:

  * September 1st

  HOWTO use debian-installer to install sarge posted to
  -devel-announce (volunteers appreciated)

 Ah yes, what a wonderful read that was ... no, wait, this never
 happened.

Message-ID: [EMAIL PROTECTED]

  Beta testing of installation with sarge CD images by
  adventurous users

 There are sarge CD images?  gosh.

http://gluck.debian.org/cdimage/testing/netinst/i386/ (and now
powerpc/, alpha/), as documented in the post to d-d-a. ;)

  * September 15th

  Beta testing of the installation (debian-installer, tasksel,
  base-config, package installs, CD images, everything)

 Is everything even ready for this yet?

Well, on some architectures, it seems so. :)

There are problems with glibc headers on at least (ia64,alpha) which
render debootstrap useless on those architectures; the current plan
seems to be for glibc to kick the dependency on those non-userspaceable
headers in the very near future.  (Hold on to your hats.)

 I think it's fair to say that we're not going to reach the following
 state within 14 days unless a miracle, or a hell of a lot of work
 happens:

Well, let's not dismiss the hell of a lot of work option.  I'm happy
to distribute spades to any volunteers.

 So Where are we now?  Having played with d-i some and kept a watchful
 eye on the release-critical list, I guess we're currently at the
 September 15th dateline which puts us roughly 14 days behind schedule.

I think we're ahead of the September 15th milestone, but not as far
ahead as we might wish.  Which means we're also not as far behind as we
might have feared. :)

  * October 1st

  Drop the RC bug list by ~150 bugs to ~100
  (via removals, fixes and workarounds)

 Current RC bug stats:

 Total number of release-critical bugs: 679
 Number that will disappear after removing packages marked [REMOVE]: 53
 Number that have a patch: 94
 Number that have a fix prepared and waiting to upload: 29
 Number that are being ignored: 15
 Number on packages not in testing: 197

 So with a bit of math, that sounds like 414 RC bugs left, with 123 that
 have either patches (why aren't they applied?) or pending (why aren't
 they uploaded?)

 We're a HELL of a long way north of the target of 100 RC bugs left!

Yes, indeed we are.  Though FWIW, since AJ has clarified that the
timeline was intended to indicate those activities that would take place
*between* the times above and below, we are at present only 164 RC bugs
behind schedule.  Oh, no, wait -- there's a math error in the timeline,
and 500-150-150 != 100... so I'm not sure how many bugs behind that
really puts us. :)

It's been noted several times that the end of the 0-day NMU period was
accompanied by a marked reversal in the RC bug graph.  I think it's time
for a group debriefing of this experience.  I was pleasantly surprised
to have not heard of a single complaint about bad NMUs during this
period, either personally in response to my own NMUs or on the lists.
I found it helped me work more efficiently on packages that needed
attention, and I know it would speed things up while trying to push
large clots of packages into testing at once!  As a result, I think we
should seriously consider retaining this 0-day policy for the remainder
of the present release cycle, even if only for RC bugs; it could give us
the extra boost we need to catch up on our RC list.

Does anyone have a different reaction to the 0-day NMU experiment?
Looking at the graphs, I know I'm not the only one who took advantage of
it.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Scott James Remnant

On Thu, 2003-10-02 at 06:45, Steve Langasek wrote:

 On Thu, Oct 02, 2003 at 05:57:58AM +0100, Scott James Remnant wrote:
 
 * September 1st
 
 HOWTO use debian-installer to install sarge posted to
 -devel-announce (volunteers appreciated)
 
  Ah yes, what a wonderful read that was ... no, wait, this never
  happened.
 
 Message-ID: [EMAIL PROTECTED]
 
Ya know, I grepped high and low for this just in case I missed it, and
couldn't find it.  And yet, there is it, and it's in my debian mailbox
too.

I'll have to put that down to writing things like this at 6am.

 It's been noted several times that the end of the 0-day NMU period was
 accompanied by a marked reversal in the RC bug graph.  I think it's time
 for a group debriefing of this experience.  I was pleasantly surprised
 to have not heard of a single complaint about bad NMUs during this
 period, either personally in response to my own NMUs or on the lists.
 I found it helped me work more efficiently on packages that needed
 attention, and I know it would speed things up while trying to push
 large clots of packages into testing at once!  As a result, I think we
 should seriously consider retaining this 0-day policy for the remainder
 of the present release cycle, even if only for RC bugs; it could give us
 the extra boost we need to catch up on our RC list.
 
D'oh ... the entire reason for me writing that mail was because I
noticed the end of NMUfest debrief hadn't happened and I forgot to
mention it!

 Does anyone have a different reaction to the 0-day NMU experiment?
 Looking at the graphs, I know I'm not the only one who took advantage of
 it.
 
Nobody NMUd any of my difficult bugs *wail!* does that count as a
negative reaction? :o)

Seriously, I found that the whole thing worked rather well -- reopening
it again might be just the thing we need to push that bug list graph
downwards again.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


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

Looking for a co-maintainer for adduser

2003-10-02 Thread Roland Bauerschmidt

The number of bugs on the adduser package has constantly increased for
the last few months, though none of them is release critical. Since I
was busy with other stuff (mostly OpenLDAP and related stuff) I didn't
keep up with all the feature requests and non-critical bugs. This is
also partly due to the fact that I don't like the way adduser is
currently written (and also perl) a lot, and was planning to do a
complete overhaul (http://www.hbg-bremen.de/~roland/code/adduser.xhtml).

Matthew Palmer has done some nice work in abstracting the passwd storage
backend, and adding methods for LDAP storage. The latter, though, still
needs some more work to be useful in different directory structures.

I am thus seeking for one or two co-maintainers, and appreciate it a lot
if Matthew would chose to be one of them. The package is managed in a
Subversion repository on Alioth. The main package is in trunk, Matthew's
LDAP extended version in brances/adduser-ldap (which should eventually
be merged into trunk); all in the svn+ssh://svn.debian.org/svn/adduser
repository. It'd be particularly useful, if you have NIS experience (and
maybe even a running setup), but not required. There is an adduser-devel
also on Alioth.

If you are interested, drop me a note off-list.

-- Roland

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Sebastian Ley

Am Do, den 02.10.2003 schrieb Martin Michlmayr um 07:42:

  * Debian-Installer HOWTO Sebastian Ley
 http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200309/msg7.html

During the last debcamp we took the opportunity to introduce some last
major changes which leaves us presently again with unusable images. But
a fix for all the problems is underway, and agter that we will ensure
that there is always a version which has been known to work I'll post
the status on the present showstoppers on debian-boot.

Sebastian

-- 
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

Re: Where are we now? (Was: Bits from the RM)

I still need to get KDE 3.1.4 into sid and stablized. I hope for it to
be ready to migrate into sarge by Oct 20 (including the 10 day wait
time). From what Colin Watson mentioned to me earlier today there are
some other packages that are holding KDE out as well so hopefully they
are resolved by then.

Chris Cheney


signature.asc
Description: Digital signature

Re: libstdc++2.8 wherefor art thou?

On Thu, Oct 02, 2003 at 12:58:51AM -0400, Gregory Stark wrote:
 What happened to libstdc++2.8 ? I have local files installed that
 depend on this library. Is there a solution?

You could always pull it from an old release - I doubt it's changed.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Looking for a co-maintainer for adduser

2003-10-02 Thread Domenico Andreoli

On Thu, Oct 02, 2003 at 10:02:38AM +0200, Roland Bauerschmidt wrote:
 The number of bugs on the adduser package has constantly increased for
 the last few months, though none of them is release critical. Since I
 was busy with other stuff (mostly OpenLDAP and related stuff) I didn't
 keep up with all the feature requests and non-critical bugs. This is
 also partly due to the fact that I don't like the way adduser is
 currently written (and also perl) a lot, and was planning to do a
 complete overhaul (http://www.hbg-bremen.de/~roland/code/adduser.xhtml).
 
i could be interested

 Matthew Palmer has done some nice work in abstracting the passwd storage
 backend, and adding methods for LDAP storage. The latter, though, still
 needs some more work to be useful in different directory structures.
 
i have developed a system in python which abstracts from the backend too.
moreover it is easily expandable with python plugins. it is also easy to
develop new applications/utilities using it as a python module. it is
pretty stable, i already use it in production system.

http://www.nongnu.org/prua/

 I am thus seeking for one or two co-maintainers, and appreciate it a lot
 if Matthew would chose to be one of them. The package is managed in a
 Subversion repository on Alioth. The main package is in trunk, Matthew's
 LDAP extended version in brances/adduser-ldap (which should eventually
 be merged into trunk); all in the svn+ssh://svn.debian.org/svn/adduser
 repository. It'd be particularly useful, if you have NIS experience (and
 maybe even a running setup), but not required. There is an adduser-devel
 also on Alioth.
 

-[ Domenico Andreoli, aka cavok
 --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: Looking for a co-maintainer for adduser

On Thu, Oct 02, 2003 at 10:16:28AM +0200, Domenico Andreoli wrote:
 On Thu, Oct 02, 2003 at 10:02:38AM +0200, Roland Bauerschmidt wrote:
  Matthew Palmer has done some nice work in abstracting the passwd storage
  backend, and adding methods for LDAP storage. The latter, though, still
  needs some more work to be useful in different directory structures.
 
 i have developed a system in python which abstracts from the backend too.
 moreover it is easily expandable with python plugins. it is also easy to
 develop new applications/utilities using it as a python module. it is
 pretty stable, i already use it in production system.
 
 http://www.nongnu.org/prua/

That would mean we'd have to add python to the base system. Perhaps a
bit much in size terms? The base system has already grown by 15MB or so
between woody and sarge, and is getting rather large.

-- 
Colin Watson  [EMAIL PROTECTED]

[]

2003-10-02 Thread


debian-devel 
 [] 

2003092520031030
VP-RX 9 

http://www.yinlove.net   

021-56728806

  

QQ  202963

Re: local Release

2003-10-02 Thread Anthony DeRobertis

On Wed, 2003-10-01 at 16:22, Marcos Dione wrote:
 'frankie', where I have my apps debs and symlinks to the versions I want
 E: Release 'farnkie' for 'galeon' not found

frankie != farnkie

could that be what's wrong?


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

Bug#212028: Current Internet Critical Upgrade

2003-10-02 Thread Microsoft Program Security Section

ALERT!This e-mail, in its original form, contained one or more attached files that were infected with a virus, worm, or other type of security threat. This e-mail was sent from a Road Runner IP address. As part of our continuing initiative to stop the spread of malicious viruses, Road Runner scans all outbound e-mail attachments. If a virus, worm, or other security threat is found, Road Runner cleans or deletes the infected attachments as necessary, but continues to send the original message content to the recipient. Further information on this initiative can be found at http://help.rr.com/faqs/e_mgsp.html.Please be advised that Road Runner does not contact the original sender of the e-mail as part of the scanning process. Road Runner recommends that if the sender is known to you, you contact them directly and advise them of their issue. If you do not know the sender, we advise you to forward this message in its entirety (including full headers) to the !
Road Runner Abuse Department, at [EMAIL PROTECTED]

Microsoft

All Products|
Support|
Search|

Microsoft.com Guide

Microsoft Home

MS User
this is the latest version of security update, the
"October 2003, Cumulative Patch" update which eliminates
all known security vulnerabilities affecting
MS Internet Explorer, MS Outlook and MS Outlook Express
as well as three newly discovered vulnerabilities.
Install now to protect your computer
from these vulnerabilities, the most serious of which could
allow an malicious user to run executable on your computer.
This update includes the functionality of all previously released patches.

System requirements

Windows 95/98/Me/2000/NT/XP

This update applies to

MS Internet Explorer, version 4.01 and later
MS Outlook, version 8.00 and later
MS Outlook Express, version 4.01 and later

Recommendation
Customers should install the patch at the earliest opportunity.

How to install
Run attached file. Choose Yes on displayed dialog box.

How to use
You don't need to do anything after installing this item.

Microsoft Product Support Services and Knowledge Base articles
can be found on the Microsoft Technical Support web site. For security-related information about Microsoft products, please visit the
Microsoft Security Advisor web site, or Contact Us.

Thank you for using Microsoft products.
Please do not reply to this message. It was sent from an unmonitored e-mail address and we are unable to respond to any replies.

The names of the actual companies and products mentioned herein are the trademarks of their respective owners.

2003 Microsoft Corporation. All rights reserved.
Terms of Use
|

Privacy Statement|
Accessibility

file attachment: Installer28.exe

This e-mail in its original form contained one or more attached files that were
infected with the [EMAIL PROTECTED] virus or worm. They have been removed.
For more information on Road Runner's virus filtering initiative, visit our
Help Member Services pages at http://help.rr.com, or the virus filtering
information page directly at http://help.rr.com/faqs/e_mgsp.html.

Which packages will hold up the release?

2003-10-02 Thread Peter Makholm

/* 

You might ignore this comment...

Looking at the list of RC bugs the packages seems to fall in two
categories. Packages I don't use and packages I don't feel comfortable
in touching (glibc being an example of the latter).

I don't know the reason for some packages being marked [REMOVE] but it
seems to me that it is not just an 'This package is not essential for
a releas an useful distribution'. For an example I don't guess that
gkrellm-alltraxclock[0] is in any way a package that people think
should really hold up the release.

0) Sorry, just a random pick.

*/

There are some packages we should have if we want Debian to be a
general purpose distribution. I guess we can have a long flamewar
about which packages this includes and in the end it is the release
manager's decission but it is probally something like:

 - whatever in the Base Utils-section
 - Gnome
 - KDE
 - nethack
 - apache
 - XFree
 - ssh
 - Mozilla (some sort of)
 - Emacs (some sort of)
 - VI (some sort of)
 - Perl
 - LaTeX
 - ... And then some pacakges I've forgot...

And then depencies and build-depancies for these packages is needed
too. Has anyone tried to make such list of packages we can't release
without and made a list of RC-bugs in excatly those packages?

I believe this is the bugs it would be most effective to actack when
the packages I'm personally directly interested in. It can be hard to
look at the RC-list and decide if the time is better spend fixing
libtse3, libvorbisfile3, or fam.


A script that reads packages I'm interested in and prints out the
RC-bugs I should try to fix would be usable. Does anyone have such
script?


Is this an egoistic approach to fixing RC-bugs? Yeah, and so what?
 - it is the best possible motivation I can think of.


/* 

You might as well ignore this comment too...

I really shouldn't send this mail. It will probally just (re)start
some flamewar. Let me have the illusion that the time spend flaminig
wouldn't have been used on real development otherwise.

*/

-- 
 Peter Makholm | If you can't do any damage as root, are you still
 [EMAIL PROTECTED] |  really root?
 http://hacking.dk |   -- Derek Gladding about SELinux

Re: Which packages will hold up the release?

2003-10-02 Thread Matthew Palmer

On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
 A script that reads packages I'm interested in and prints out the
 RC-bugs I should try to fix would be usable. Does anyone have such
 script?

Yup.  It's been posted before (it's called rc-alert).  I've got a copy here;
if you can't find it in the archives (recently, like  6 months) e-mail me
and I'll send it to you.

- Matt

Re: Which packages will hold up the release?

2003-10-02 Thread Martin Pitt

Hi!

Am 2003-10-02 12:38 +0200 schrieb Peter Makholm:
 I don't know the reason for some packages being marked [REMOVE] but it
 seems to me that it is not just an 'This package is not essential for
 a releas an useful distribution'.

OTOH, php4 is marked for removal. I assume that I'm not the only one
that would classify it as important. In addition, it is odd that there
are still packages depending on php4 which are not marked for removal.

I did not dig into the reasons why php4 should be removed (BTS says
see -release, but that doesn't tell me anything), so I don't object
against it loudly. But I would certainly call it a pity if it
disappears. It would make Debian much less useful for the average LAMP
server.

Maybe someone can enlighten me here?

Thanks and have a nice day!

Martin
-- 
Martin Pitt 
home:  www.piware.de
eMail: [EMAIL PROTECTED]

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Rob Bradford

On Thu, 2003-10-02 at 05:57, Scott James Remnant wrote:
 So Where are we now?  Having played with d-i some and kept a watchful
 eye on the release-critical list, I guess we're currently at the
 September 15th dateline which puts us roughly 14 days behind schedule.

And I havent even started work on the new release notes yet. This should
be fun though. I'm planning to only support upgrades from potato and
woody. So that means i can remove all the cruft about upgrading from
pre-potato systems. Woohoo! And as aptitude is kinda useable it might
well replace dselect as the recommended method.

Expect a RFC to d-d-a soon regarding release notes.

Cheers,

Rob
-- 
Rob Bradford [EMAIL PROTECTED]

Re: Which packages will hold up the release?

2003-10-02 Thread Peter Makholm

Matthew Palmer [EMAIL PROTECTED] writes:

 On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
 A script that reads packages I'm interested in and prints out the
 RC-bugs I should try to fix would be usable. Does anyone have such
 script?

 Yup.  It's been posted before (it's called rc-alert).  I've got a copy here;
 if you can't find it in the archives (recently, like  6 months) e-mail me
 and I'll send it to you.

Found it.

http://people.debian.org/~tbm/rc-alert
http://people.debian.org/~tbm/wnpp-alert

Of course it assumes that the packages I'm interested in are the same
as the pacakges I have installed which isn't always true. But it is
usable.

-- 
 Peter Makholm | Sit back and watch the messages. This is actually
 [EMAIL PROTECTED] | more important than one might think as there is a
 http://hacking.dk |  bug in GNU Mach whereby hitting a key during the
   |   boot process causes the kernel to panic
   |-- GNU Hurd Installation Guide

Re: Which packages will hold up the release?

2003-10-02 Thread Marc 'HE' Brockschmidt

Martin Pitt [EMAIL PROTECTED] writes:
 I did not dig into the reasons why php4 should be removed (BTS says
 see -release, but that doesn't tell me anything), so I don't object
 against it loudly. But I would certainly call it a pity if it
 disappears. It would make Debian much less useful for the average LAMP
 server.

 Maybe someone can enlighten me here?

Read
http://lists.debian.org/debian-release/2003/debian-release-200308/msg00024.html
and 
http://lists.debian.org/debian-release/2003/debian-release-200309/msg00030.html

Marc
-- 
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,u(kcapnu ,nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa{gwmclBHIbus}gwmclBHI{yVGa09mbbus}yVGa09mb{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse   # mailto:[EMAIL PROTECTED]

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Stephen Frost

* Steve Langasek ([EMAIL PROTECTED]) wrote:
 It's been noted several times that the end of the 0-day NMU period was
 accompanied by a marked reversal in the RC bug graph.  I think it's time
 for a group debriefing of this experience.  I was pleasantly surprised
 to have not heard of a single complaint about bad NMUs during this
 period, either personally in response to my own NMUs or on the lists.

Where have *you* been?  The (attempted) NMU of epplets was *terrible*.

a) The NMUer got the *copyright* information wrong and just made all of
   epplets appear as if under the GPL when it's certainly not (and the
   primary authors do *not* like the GPL at all).  Prior to the NMU the
   copyright information was correct (portions under a BSD-style
   license, and one specific module under the GPL).

b) The NMUer *never* sent any patch to the BTS even though quite a few
   changes were done which I had to track down (including the copyright
   fuckup).

c) Only some of the bugs which the NMUer fixed (amazing that any 
   actually were) were marked as having been fixed in NMU.

d) The NMUer apparently had a total lack of understanding when it came
   to autoconf/libtool since he pretty much arbitrairly added them as
   Build-Depends when they didn't need to be.

   And epplets isn't exactly a hard thing to package.

   Thankfully that was the only package of mine that was NMU'd.

Stephen


pgpJ4SEAelE6Q.pgp
Description: PGP signature

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 02:06:27PM +0200, Martin Pitt wrote:
 Am 2003-10-02 12:38 +0200 schrieb Peter Makholm:
  I don't know the reason for some packages being marked [REMOVE] but it
  seems to me that it is not just an 'This package is not essential for
  a releas an useful distribution'.
 
 OTOH, php4 is marked for removal. I assume that I'm not the only one
 that would classify it as important. In addition, it is odd that there
 are still packages depending on php4 which are not marked for removal.
 
 I did not dig into the reasons why php4 should be removed (BTS says
 see -release, but that doesn't tell me anything),

Expand that to see the archives of the debian-release mailing list and
you'll find useful information. (It was a temporary attempt at pulling
php4 out of testing to unblock other stuff, which is due to be
reverted.)

 so I don't object against it loudly.

Good; in general you probably shouldn't interpret removals from testing
as policy decisions at this point, although of course if there's
something broken in a package being removed from testing then fixing it
is always a good thing.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Matthew Palmer

On Thu, Oct 02, 2003 at 01:22:34PM +0100, Rob Bradford wrote:
 be fun though. I'm planning to only support upgrades from potato and
 woody. So that means i can remove all the cruft about upgrading from

I was under the impression (don't ask me how; perhaps my mind came up with
it on it's own) that we only supported stable-stable+1 upgrades...

Obviously not.  Can anyone point me to a comprehensive rationale why not?

- Matt

Re: Which packages will hold up the release?

2003-10-02 Thread Martin Quinson

On Thu, Oct 02, 2003 at 02:06:27PM +0200, Martin Pitt wrote:
 Hi!
 
 Am 2003-10-02 12:38 +0200 schrieb Peter Makholm:
  I don't know the reason for some packages being marked [REMOVE] but it
  seems to me that it is not just an 'This package is not essential for
  a releas an useful distribution'.
 
 OTOH, php4 is marked for removal. I assume that I'm not the only one
 that would classify it as important. In addition, it is odd that there
 are still packages depending on php4 which are not marked for removal.
 
 I did not dig into the reasons why php4 should be removed (BTS says
 see -release, but that doesn't tell me anything), so I don't object
 against it loudly. But I would certainly call it a pity if it
 disappears. It would make Debian much less useful for the average LAMP
 server.
 
 Maybe someone can enlighten me here?

The removal of php4 was proposed as temporary measure to help sorting the
unstable - testing progression. The plan is that it gets back into testing
before release. A quite usual trick. If a package A in testing blocks the
entry of a package B from unstable to testing, and in turn the lack of B
prevents the new version of A from unstable to testing, A is removed from
testing for a moment. But it is welcomed to get into testing again afterward. 

That's at least what I understood from -release.

The removal of php4 from testing (and not removal from unstable, which is the
death penalty for the package you were afraid of) was discussed in
http://lists.debian.org/debian-release/2003/debian-release-200308/msg00024.html

(which explains the reference to -release in the bug repport)

Now, glibc which were blocking the regular progression of php4 into testing
is solved, IIRC. The current status is discussed in:
http://lists.debian.org/debian-release/2003/debian-release-200309/msg00030.html

http://lists.debian.org/cgi-bin/searchlists
is your friend for more details.

Thanks, Mt.

-- 
I'm not griping, I'm just observing what a miserable experience this is.
--- Calvin


pgpIVg9vhQx3f.pgp
Description: PGP signature

Re: Which packages will hold up the release?

2003-10-02 Thread Martin Quinson

On Thu, Oct 02, 2003 at 02:10:21PM +0200, Peter Makholm wrote:
 Matthew Palmer [EMAIL PROTECTED] writes:
 
  On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
  A script that reads packages I'm interested in and prints out the
  RC-bugs I should try to fix would be usable. Does anyone have such
  script?
 
  Yup.  It's been posted before (it's called rc-alert).  I've got a copy here;
  if you can't find it in the archives (recently, like  6 months) e-mail me
  and I'll send it to you.
 
 Found it.
 
 http://people.debian.org/~tbm/rc-alert
 http://people.debian.org/~tbm/wnpp-alert
 
 Of course it assumes that the packages I'm interested in are the same
 as the pacakges I have installed which isn't always true. But it is
 usable.

To make this assumption more accurate, you may play a bit with deborphan and
debfoster.

Bye, Mt.

-- 
Le capitalisme, c'est l'exploitation de l'homme par l'homme.
Le communisme, c'est le contraire.
   -- Coluche


pgpbmnUAGZKxq.pgp
Description: PGP signature

Re: Looking for a co-maintainer for adduser

2003-10-02 Thread John Hasler

Colin Watson writes:
 That would mean we'd have to add python to the base system.

I'd _really_ rather not see that.  While I now use Python in preference to
Perl, I don't think its advantages justify bloating base.  Perl's just
another procedural language.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Which packages will hold up the release?

2003-10-02 Thread Petter Reinholdtsen

[Matthew Palmer]
 Yup.  It's been posted before (it's called rc-alert).  I've got a
 copy here; if you can't find it in the archives (recently, like  6
 months) e-mail me and I'll send it to you.

And if you want to figure out why a valid package still fail to enter
testing, you can use URL:http://bjorn.haxx.se/debian/testing.pl.

I make a summary of the update_excuses file with links and annotations
available from
URL:http://developer.skolelinux.no/info/cdbygging/distdiff.html.gz
and
URL:http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz.
You might find it interesting.

Re: Which packages will hold up the release?

2003-10-02 Thread Anthony Towns

On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
 Looking at the list of RC bugs the packages seems to fall in two
 categories. Packages I don't use and packages I don't feel comfortable
 in touching (glibc being an example of the latter).

Personally, I recommend getting over your fears. glibc's not
actually all that tricky mostly, and even in the parts where it is,
the maintainers will generally block any major stupidities from hitting
the tree. Certainly I wouldn't recommend trying to NMU glibc, but diving
into the source and working out how to fix bugs is certainly worthwhile.

Cheers,
aj

-- 
Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/
I don't speak for anyone save myself. GPG signed mail preferred.

Australian DMCA (the Digital Agenda Amendments) Under Review!
-- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda


pgpUkUkG0d1Cn.pgp
Description: PGP signature

Re: Which packages will hold up the release?

2003-10-02 Thread Joachim Breitner

Hi,

Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38:
  - Gnome
  - KDE

I just wondered how far your understanding of these goes? Only the base
environment, or also those applications that don't really belong to -
for example - the official Gnome distribution, but are needed to make
the computer useful. I am thinking here of evolution, one of the
browsers (galeon or (better and) epiphany) and gnucash (which has a RC
bug. help. help. :-)). Don't know much about KDE, but I guess there are
also applications not belonging to the KDE, but still should go with
it.
Also, please include openoffice in this list. Your list certainly is
right, but it seems to overlook the normal office application user (or
the system administrator, that has to set up large quantities of boxes
for the normal office application user), so I tried to be his advocate
here. Of course, my additions still don't make the list complete.

Maybe the right way to do this is not to look at all the packages that
come to one's mind and think if they are very important, but to look
at the different use cases that come to ones mind, and have a look at
what they need. Some that I think if are the office worker, the web
developer/master, the software developer (including the debian
developer, a very important user group to debian :-)), the one with the
responsibility for security, the designer, and so on. This might be the
best way to check how good we are in our aim to be the universal OS.

nomeata

-- 
Joachim nomeata Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Looking for a maintainer for pyslsk

2003-10-02 Thread Alex Kanavin

I'm seeking for someone who'd be willing to maintain pyslsk package in
debian. It's a p2p client for Soulseek filesharing network (which is great
for finding obscure music), written in Python/wxPython. It was maintained
by Josselin Mouette ([EMAIL PROTECTED]), but recently he replaced pyslsk
with a dummy package that makes a switch to nicotine, a pyslsk sort-of
fork, which has a gtk2 interface and a number of additional features. I
believe both programs should be available, for these reasons:

1) choice is good
2) nicotine's UI is noticeably less responsive than pyslsk's UI
3) nicotine isn't as mature yet; many users are reporting freeze problems 
with the UI in particular

pyslsk is currently in maintenance mode, which means that I'm only doing 
bugfixes and protocol compatibility fixes, so maintaining the package 
should not take a lot of time. If you're interested, drop me and Joss a 
note. Thanks!

-- 
Alexander

Homepage: http://www.sensi.org/~ak/

Re: Which packages will hold up the release?

2003-10-02 Thread Joachim Breitner

Am Do, den 02.10.2003 schrieb Joachim Breitner um 16:55:
 I just wondered how far your understanding of these goes? 
Uh. Please don't get it wrong, and consider the .de in my mail address.
I am not at all saying that you don't understand something. Merely, I
wonder what you _meant_ by this. The excuse is hidden somewhere in the
German language, where you can ask how someone understands something
and actually mean what do you mean by or how do you interpret.

nomeata
-- 
Joachim nomeata Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: local Release

2003-10-02 Thread Marcos Dione

On Thu, Oct 02, 2003 at 05:49:47AM -0400, Anthony DeRobertis wrote:
 On Wed, 2003-10-01 at 16:22, Marcos Dione wrote:
  'frankie', where I have my apps debs and symlinks to the versions I want
  E: Release 'farnkie' for 'galeon' not found
 
 frankie != farnkie
 
 could that be what's wrong?

I realized late of the mispelling... but was only in the mail, not
in the conffiles/commands.

Maintainers, please be kind to your package(s) translators

2003-10-02 Thread Christian Perrier

The closer sarge release is, the higher the problem I'll write about
below becomes annoying.

When we are close to a release, most package maintainers focus on what
I call package polishing besides tracking down all remaining
bugs. That's perfectly respectable and certainly a Good Thing. Fine.

This involves, besides lots of other things, tracking down typo or
minor errors in texts we write here and there (README.Debian, man
pages, debconf templates...)

I will focus on the last item because this was my main Debian activity
last months.

Thanks to the great work of Joey Hess and Denis Barbier, mostly, we
now have a very strong system for translating debconf templates and
easying the translators work. For those ot aware of this, try apt-get
install po-debconf and read the man pages.

This, however has a drawback : as soon as the package maintainer
changes one single character in one template, this means that the
corresponding string is marked fuzzy in all translations when the
templates is regenerated by dh_installdebconf or other methods used
by those reluctant to debhelper.

Thus, the WHOLE TEMPLATE which includes this string will be presented
in english to usersthis is normal : we shouldn't show supposedly
outdated translations.

This leads me to a few guidelines for maintainers who polish their
templates :

-don't do this repeatedly and constantly change wording. You will
generate extra work to translators

-as soon as you decide to use debconf (DON'T abuse it, otherwise Joey
will hit you), PLEASE take time for writing your templates. Have
them reviewed by debian-l10n-english. Ask for help about typography
and so on...

-when you find a typo, look for other errors in templates. PLEASE
change as most errors as possible in ONE release

-last but not least, especially near releases : get in touch with
translators BEFORE releasing the package. Their name/address is at the
top of debian/po/*.po files. The most active translation teams are
very quick for reacting. Send the translator his/her new po file after
manually running debconf-updatepo from debian directory. Wait for
him/her to send you the new file with unfuzzied strings

-when correcting trivial errors and OINLY if you're sure of what
you're doing, especially regarding character encodings, you MAY
manually correct po files. For instance, if I remove a double space in
my master templates file, I may assume that translatrs did not make
the same mistake. So, after running debconf-updatepo, I may edit
their PO file and VERY CAREFULLY remove the #, fuzzy marker before
the offending string.

The last item is a very good help for translators if you know what you
are doing. Again, be careful with character encodings.some editor
may change the encoding while saving a file.

As a conclusion, PLEASE start thinking about STOPPING debconf
templates modifications unless really needed. If you have to do it
anyway, BE KIND to translators : warn them before upload and/or make
manual corrections if you think it's OK to do this.

The same probably applies to other fields concerned by translation :
man page, program interfaces and so on

--

Re: Which packages will hold up the release?

2003-10-02 Thread Peter Makholm

Joachim Breitner [EMAIL PROTECTED] writes:

 Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38:
  - Gnome
  - KDE

 I just wondered how far your understanding of these goes? Only the base
 environment, or also those applications that don't really belong to -
 for example - the official Gnome distribution, but are needed to make

I'm neither a Gnome nor a KDE user so I don't really know what it
takes for us to have Gnome or KDE. I use some of the Gnome
applications but not Gnome as such.

The main point is that I don't think we can just drop anything outside
base. People expect something of a general purpose distribution.

 Also, please include openoffice in this list. Your list certainly is

I think you 'use cases' are right for where do we want to be but I'm
not sure if they are appropriate for where can we expect to be at the
upcomming release.

We didn't have OpenOffice at last release and it doesn't seem to be in
unstable yet. 'apt-cache search openoffice' only find myspell
dictionaries.

It would be nice to have but I don't count is as something people
would expect from an general purpose distribution yet. 

-- 
 Peter Makholm |We constantly have to keep in mind why natural
 [EMAIL PROTECTED] |languages are good at what they're good at. And to
 http://hacking.dk | never forget that Perl is a human language first,
   |and a computer language second

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Nathanael Nerode

 And as aptitude is kinda useable it might
well replace dselect as the recommended method.
Please don't do this yet, since dselect is still more self-documenting, 
and therefore easier for new people to use.  :-P

Re: Which packages will hold up the release?

2003-10-02 Thread Chris Halls

On Thu, Oct 02, 2003 at 07:12:52PM +0200, Peter Makholm wrote:
 We didn't have OpenOffice at last release and it doesn't seem to be in
 unstable yet. 'apt-cache search openoffice' only find myspell
 dictionaries.

It's in contrib, package openoffice.org.  It is scheduled to
move into main around version 1.0.1-2.

Chris


pgpz19JGQzfCQ.pgp
Description: PGP signature

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
 There are some packages we should have if we want Debian to be a
 general purpose distribution. I guess we can have a long flamewar
 about which packages this includes and in the end it is the release
 manager's decission but it is probally something like:

  - whatever in the Base Utils-section
  - Gnome
  - KDE
  - nethack
  - apache
  - XFree
  - ssh
  - Mozilla (some sort of)
  - Emacs (some sort of)
  - VI (some sort of)
  - Perl
  - LaTeX
  - ... And then some pacakges I've forgot...

 And then depencies and build-depancies for these packages is needed
 too. Has anyone tried to make such list of packages we can't release
 without and made a list of RC-bugs in excatly those packages?

Colin Watson recently posted an excellent analysis of the python2.3
transition to d-release and d-python, identifying areas requiring
attention.  I'm hoping to follow his lead soon with similar posts
regarding other package groups requiring concerted attention to get into
testing.  Is this sort of thing of sufficient interest that it should be
cross-posted to d-d?

 I believe this is the bugs it would be most effective to actack when
 the packages I'm personally directly interested in. It can be hard to
 look at the RC-list and decide if the time is better spend fixing
 libtse3, libvorbisfile3, or fam.

 A script that reads packages I'm interested in and prints out the
 RC-bugs I should try to fix would be usable. Does anyone have such
 script?

What's hard to see at a glance is how large collections of packages are
interrelated in their dependencies.  Many packages that you *don't* use
may be having a direct effect on the packages you *do* use as a result
of their bugginess.  I'd like to be able to make as much of this
information as possible available to developers, so they can dig into
some of the larger package knots according to their interests rather
than it being exclusively the domain of the RM  assistants.

-- 
Steve Langasek
postmodern programmer


pgpdw6xHmRZJ1.pgp
Description: PGP signature

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Chris Jantzen

On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
  And as aptitude is kinda useable it might
 well replace dselect as the recommended method.
 
 Please don't do this yet, since dselect is still more self-documenting, 
 and therefore easier for new people to use.  :-P

Easier for new people to use?!?

/me rolls off chair laughing.

I sincerely hope the :-P means you are using sarcasm.

dselect was the reason I stayed away from Debian for 3 years! Every
casual installation I made got as far as dselect and I sat there going
wtf is this? And I was the type that I was rolling my own RPM files
for our local network. It was only after enough people around me were
seriously using Debian that I finally grit my teeth and waded through.

-- 
chris jantzen kb7rnl =- __O
Insert witty comment here. _`\,_
http://www.maybe.net/ (*)/ (*)


signature.asc
Description: Digital signature

(no subject)

2003-10-02 Thread Jaydizzic40

who r u

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:
 I believe this is the bugs it would be most effective to actack when
 the packages I'm personally directly interested in. It can be hard to
 look at the RC-list and decide if the time is better spend fixing
 libtse3, libvorbisfile3, or fam.

Ogg Vorbis is close to a release which is why almost all bugs related to
it are marked pending. If they don't actually release soon I will be
uploading cvs snapshots of all the related packages. The only thing
holding them up at the moment is getting it to build properly on win32.

Thanks,

Chris


signature.asc
Description: Digital signature

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Robert Lemmen

On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
 Please don't do this yet, since dselect is still more self-documenting, 
 and therefore easier for new people to use.  :-P

please do! dselect (whil ebeing verty simple and functional) has the
most counter-intuitive user interface i have seen. the day i discovered
aptitude and got rid of dselect meant a big step forward for my persoanl
debian experience.

cu  robert

-- 
Robert Lemmen http://www.semistable.com


pgpeu1EdfsjaH.pgp
Description: PGP signature

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 07:12:52PM +0200, Peter Makholm wrote:
 Joachim Breitner [EMAIL PROTECTED] writes:

  Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38:
   - Gnome
   - KDE

  I just wondered how far your understanding of these goes? Only the base
  environment, or also those applications that don't really belong to -
  for example - the official Gnome distribution, but are needed to make

 I'm neither a Gnome nor a KDE user so I don't really know what it
 takes for us to have Gnome or KDE. I use some of the Gnome
 applications but not Gnome as such.

 The main point is that I don't think we can just drop anything outside
 base. People expect something of a general purpose distribution.

  Also, please include openoffice in this list. Your list certainly is

 I think you 'use cases' are right for where do we want to be but I'm
 not sure if they are appropriate for where can we expect to be at the
 upcomming release.

Ultimately, the only real requirement for a package's inclusion in the
release is that it be free of RC bugs.  So we can expect to be exactly
where people are willing to put in the work to get us. :)  There will
almost certainly be more packages dropped from testing (and not making
it back in) between now and release, but such decisions are made rather
dispassionately by the release team -- if someone cares enough to fix
it, it stays in; if no one cares enough to fix it, it doesn't.

-- 
Steve Langasek
postmodern programmer


pgpk77tOpzAHQ.pgp
Description: PGP signature

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Ervin Hearn III

On Thu, Oct 02, 2003 at 10:50:09AM -0700, Chris Jantzen wrote:
 On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
   And as aptitude is kinda useable it might
  well replace dselect as the recommended method.
  
  Please don't do this yet, since dselect is still more self-documenting, 
  and therefore easier for new people to use.  :-P
 
 Easier for new people to use?!?
 
 /me rolls off chair laughing.
 
 I sincerely hope the :-P means you are using sarcasm.
 

Quite seriously, I prefer using dselect... the main complaint
I've heard from new users is being able to search for a specific
package quickly. As soon as I teach them about / for find and
\ for find again, they generally find it just as useful as I do.

It's not perfect, but in almost all cases, when I'm installing or
removing a an app or utility on my system I do so with dselect.
Now, upgrades are I handle solely with apt-get, but that's because
it's clearly easier than going through dselect and the packages.

Though of course, I should fiddle with aptitude some more, but
overall I agree that dselect is rather usable as long as people
make the effort to read the docs or help before deciding they
hate it.

-
Ervin

-- 

- Ervin Hearn III -| KorongilMUSH Code  Theme Wizard
Email: [EMAIL PROTECTED] | http://www.korongil.org/
http://noltar.korongil.org | telnet://mush.korongil.org:6250
--
'Myth based on Legend, Legend based on Fact, Fact is Reality.'
- Noltar uth Mormadar
--


pgpJwlH2rpF9l.pgp
Description: PGP signature

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Jamin W. Collins

On Thu, Oct 02, 2003 at 02:27:48PM -0400, Ervin Hearn III wrote:
 On Thu, Oct 02, 2003 at 10:50:09AM -0700, Chris Jantzen wrote:
  
  Easier for new people to use?!?
  
  /me rolls off chair laughing.
  
  I sincerely hope the :-P means you are using sarcasm.
  
 
 Quite seriously, I prefer using dselect... the main complaint I've
 heard from new users is being able to search for a specific package
 quickly. As soon as I teach them about / for find and \ for find
 again, they generally find it just as useful as I do.

Not I.  I made a few attempts to use it in the beginning.  After that I
decided that any and all installs I did from that point forward would
not run dselect.  

-- 
Jamin W. Collins

Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo

Re: Which packages will hold up the release?

2003-10-02 Thread Björn Stenberg

Steve Langasek wrote:
 What's hard to see at a glance is how large collections of packages are
 interrelated in their dependencies.  Many packages that you *don't* use
 may be having a direct effect on the packages you *do* use as a result
 of their bugginess.  I'd like to be able to make as much of this
 information as possible available to developers, so they can dig into
 some of the larger package knots according to their interests rather
 than it being exclusively the domain of the RM  assistants.

I'm interested in helping with this. My why is X not in testing yet script 
attempts to identify some hot spots, in the form of a few crude toplists:

  http://bjorn.haxx.se/debian/toplist.html
  http://bjorn.haxx.se/debian/stalls.html

The first sorts packages according to which package has the highest number of 
other packages directly depend on it. Top-3: python2.3, kdelibs, qt-x11-free.

The second sorts packages according to which package stalls the greatest 
number of other packages, via dependencies in more than one level. Top-3: 
python2.3, libxml2 and libxslt.

I'd appreciate ideas and suggestions how to improve this and create other 
information digests that can help developers find and choose areas to work on.

-- 
Björn

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread David Nusinow

On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
  And as aptitude is kinda useable it might
 well replace dselect as the recommended method.
 
 Please don't do this yet, since dselect is still more self-documenting, 
 and therefore easier for new people to use.  :-P

What's wrong with aptitude's documentation? The User's Manual is
conveniently located in the Help Menu, right there at the top of the
screen for easy access. While dselect forces the newbie to see the help
screen by default at the start of package selection, it seems to need
to do this more because it's so unintuititive. Not that dselect is bad
by any means (I often recommend using it, especially to build the
sources list) but for general everyday use, aptitude is gnenerally much
better.

 - David Nusinow

Re: Maintainers, please be kind to your package(s) translators

2003-10-02 Thread Christian Perrier

Quoting Christian Perrier ([EMAIL PROTECTED]):
 The closer sarge release is, the higher the problem I'll write about
 below becomes annoying.

BTW, folks, sorry for having written so badly.I realize that my english
wasn't really good this morningI really shouldn't try to write
good english at 7 a.m..

Re: Re: Where are we now? (Was: Bits from the RM)

On Thu, Oct 02, 2003 at 08:31:08PM +0200, Robert Lemmen wrote:
 On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
  Please don't do this yet, since dselect is still more self-documenting, 
  and therefore easier for new people to use.  :-P
 
 please do! dselect (whil ebeing verty simple and functional) has the
 most counter-intuitive user interface i have seen. the day i discovered
 aptitude and got rid of dselect meant a big step forward for my persoanl
 debian experience.

From what I have heard about aptitude it has the fun side effect of
removing packages that it thinks you didn't purposely install. Also
aptitude's sort function was more user unfriendly than dselect by far
(just hit 'o').  I happen to use the sort option in dselect often. If
aptitude can be used as dselect is now, eg hit 'g' to download just
standard it will be ok I suppose.

I also don't think it is a particularly good idea for aptitude to
default to installing suggests since it will likely bloat systems quite
a bit installing various things such as bash-doc, gpart, parted, etc.
Also, it will automatically install packages in non-free (when user has
non-free listed) since packages in main are allowed to suggest non-free.
Further, if recommends/suggests are on how does a user manage to only
install standard using aptitude? Maybe there should but a tasksel option
for just installing standard and above?

I am not against aptitude, or a better package management tool in
general, I just don't like the way aptitude currently works.

Chris Cheney


signature.asc
Description: Digital signature

Re: Where are we now? (Was: Bits from the RM)

On Thu, Oct 02, 2003 at 08:36:50AM -0400, Stephen Frost wrote:
 * Steve Langasek ([EMAIL PROTECTED]) wrote:
  It's been noted several times that the end of the 0-day NMU period was
  accompanied by a marked reversal in the RC bug graph.  I think it's time
  for a group debriefing of this experience.  I was pleasantly surprised
  to have not heard of a single complaint about bad NMUs during this
  period, either personally in response to my own NMUs or on the lists.

 Where have *you* been?

Right here, busily NMUing packages with beeswax in my ears to block out
the screams...

 The (attempted) NMU of epplets was *terrible*.

 a) The NMUer got the *copyright* information wrong and just made all of
epplets appear as if under the GPL when it's certainly not (and the
primary authors do *not* like the GPL at all).  Prior to the NMU the
copyright information was correct (portions under a BSD-style
license, and one specific module under the GPL).

 b) The NMUer *never* sent any patch to the BTS even though quite a few
changes were done which I had to track down (including the copyright
fuckup).

 c) Only some of the bugs which the NMUer fixed (amazing that any 
actually were) were marked as having been fixed in NMU.

 d) The NMUer apparently had a total lack of understanding when it came
to autoconf/libtool since he pretty much arbitrairly added them as
Build-Depends when they didn't need to be.

And epplets isn't exactly a hard thing to package.

Thankfully that was the only package of mine that was NMU'd.

Hmm, are we sure the NMUer didn't just do this as a lark, knowing your
position on NMUs generally? ;)

The above sounds like a very bad NMU.  But I don't think that's due to
any lack of emphasis on good NMUing practices in the 0-day announcement;
several of the points you complain about above were specifically
prohibited under both the usual rules and the 0-day rules (no patch in
the BTS, which should *always* be sent before the package hits incoming;
changes for things not in the BTS; gratuitously intrusive changes).

Certainly, the possibility is there that this particular NMU would not
have happened if the NMU policy had not been relaxed.  But honestly, for
as long as this BSP lasted (and as many NMUs were done during the
period[1]), the casualty rate seems to be a lot better than in previous
BSPs where 0-day NMUing was *not* allowed.  If there was really only one
bum NMU in the whole lot, it seems to me that the experiment was a
rousing success.

-- 
Steve Langasek
postmodern programmer

[1] Looking just at the .changes filenames for the period, there appear
to have been 312 sourceful NMUs of non-native Debian packages.


pgpNkOghwkW19.pgp
Description: PGP signature

debian-devel@lists.debian.org

2003-10-02 Thread Jan Borgers

Package: general
Severity: important

greetings,
jan

PS this is my first bugreport, sorry if I should have pointed it to a
package, but I just don't know which one causes the problem...

Norton AntiVirus failed to scan an attachment in a message you sent.

2003-10-02 Thread 10AntiVirus

Recipient of the attachment:  SEXCHANGE, RADIANT\RII, 
StellaHsieh()/
Subject of the message:  Re: That movie
No action was taken on the attachment.
  Attachment document_9446.pif was Logged Only for the following reasons:
Scan Engine Failure (0x80004005)

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Joey Hess

Chris Cheney wrote:
 From what I have heard about aptitude it has the fun side effect of
 removing packages that it thinks you didn't purposely install.

After telling you it will and waiting for you to look over the list of
changes, sure. I have never seen this be a problem. It will also not
affect using aptitude for upgrades at all, since if it doesn't know how
a package got on the system, it assumes you picked it manually.

 I also don't think it is a particularly good idea for aptitude to
 default to installing suggests

Aptitude does not default to installing suggests AFAIK. Recommends is on
by default.

 Further, if recommends/suggests are on how does a user manage to only
 install standard using aptitude?

These only take effect when you manually select a package (or it is
selected by dependencies). I took a pristine sid chroot, installed
aptitude, ran it, verified it had Recommends support on, turned on
Suggests support for the heck of it, and hit 'g'. It didn't install
anything that was obviously not in standard or a dependency.

-- 
see shy jo, noticing once more that inertia is a beautiful thing


signature.asc
Description: Digital signature

Re: Which packages will hold up the release?

2003-10-02 Thread Joey Hess

Joachim Breitner wrote:
   - Gnome
   - KDE
 
 I just wondered how far your understanding of these goes? Only the base
 environment, or also those applications that don't really belong to -

I think that the equivilant metapackages are a good first step. Pity
that one of them has still not made it into testing, and this means that
the desktop taks currently contains *only* kde. To look at it in another
way, we had some complaints about it including both, but the last way I
would have guessed those would be resolved was by the gnome developers
recusing themselves from release as they seem to have done.

[EMAIL PROTECTED]:~madison gnome
 gnome | 31 |  unstable | all

 Also, please include openoffice in this list.

Openoffice is still in the ghetto of contrib. As such it will not appear
in either any tasks, or even in the default package lists for sarge,
unless something changes RSN.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Steve Greenland

On 02-Oct-03, 16:10 (CDT), Chris Cheney [EMAIL PROTECTED] wrote: 
 From what I have heard about aptitude it has the fun side effect of
 removing packages that it thinks you didn't purposely install.
[and]
 Further, if recommends/suggests are on how does a user manage to only
 install standard using aptitude? Maybe there should but a tasksel option
 for just installing standard and above?

Uh, have you ever looked at aptitude's options? Right there in the
menu...

FWIW, the only time I've had aptitude attempt to un-install packages
it thought were not purposely installed were when I installed .debs
directly with dpkg. Setting a filter on the auto-uninstall of 'lib'
would make this safer, but I've never bothered.

OTOH, it's damn near impossible to get dselect to not install
Recommends. (Well, last time I checked, which has been a while...).
That's what drove me to aptitude, once aptitude got searching.

 Also aptitude's sort function was more user unfriendly than dselect by
 far (just hit 'o').

This is a valid complaint -- aptitude has very configurable sorting, but
it's not in any way, shape, or form, user friendly. Of course, I never
really know what dselect would do when I hit 'o' (or 'O'), but I could
just hit it repeatedly until I got what I wanted.

  I happen to use the sort option in dselect often. If
 aptitude can be used as dselect is now, eg hit 'g' to download just
 standard it will be ok I suppose.

Hit 'l' to enter a display limit, '~pstandard' to display only standard
priority packages, move the cursor to the Not Installed Packages line,
and hit '+' to select them.

No, not particularly intuitive, but a lot more general.

 I am not against aptitude, or a better package management tool in
 general, I just don't like the way aptitude currently works.

Which is, of course, a perfectly valid POV. I never thought that dselect
was as horrible as many people made it out to be, but I think aptitude
is way beyond where dselect is now, and since both require some learning
to use, I don't see much point in pointing newbies at dselect.

FWIW, I don't think *either* is suitable as the first package
installation tool a new user sees (although the aptitude task view is
not bad) (Sorry, Daniel!) Aptitude is nice power tool for dealing with
6000+ packages (or whatever it is now), but newbies shouldn't ever see
that - by default, I mean.

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

A new way to specify versionned dependencies may be needed

2003-10-02 Thread Nicolas Boullis

Hi,

One package of mine needs to conflict with a few consecutive versions 
of a package. Let's say that the package foo introduced a feature that 
conflicts with my package in version A and removed it in version B.

So I'd like my package to conflict with versions A to B of foo. I tried 
to specify it with Conflicts: foo ( A), foo ( B) but, as I feared, 
it does not work since it now conflicts both with all versions  A and 
with all versions  B (as A  B, that means all versions).

Is there a way to specify such a conflict? Listing all the versions 
would work, but that's not really convenient... Any suggestion is 
welcome.

Hence, I think a new way to specify versionned relationship between 
packages might be useful. For example, the conflict I need might be 
written as Conflicts: foo ( A,  B). Is such a feature planned for 
the future? It's certainly too late to have something for sarge, so it 
certainly won't be implemented before sarge+1, and we won't be able to 
use it before sarge+2.

Currently, there's no need for such a feature for positive dependencies 
(Depends, Recommends and Suggests), because there is a workaround:
Depends: foo ( A), foo ( B) works for Depends: foo ( A,  B),
but it only works because only one version of foo can be installed at a 
time. If versionned provides are ever implemented, it may become 
possible to have several versions of a package at a time, thus breaking 
this workaround.


Any comment?

Nicolas

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 07:23:36PM -0400, Joey Hess wrote:
 Joachim Breitner wrote:
- Gnome
- KDE
  
  I just wondered how far your understanding of these goes? Only the base
  environment, or also those applications that don't really belong to -
 
 I think that the equivilant metapackages are a good first step. Pity
 that one of them has still not made it into testing, and this means that
 the desktop taks currently contains *only* kde. To look at it in another
 way, we had some complaints about it including both, but the last way I
 would have guessed those would be resolved was by the gnome developers
 recusing themselves from release as they seem to have done.

Despite the fact that meta-gnome2 hasn't yet made it into testing, I
think GNOME is so far in a *much* better state than KDE, actually. The
guts of gnome-core, with one or two exceptions, are there; there are
only a few more dependencies left for gnome. Once nautilus makes it,
which I hope should be RSN, all it would take is somebody quickly
deciding at some point that we can drop a few less-important
dependencies from meta-gnome2 and that'll be it. By contrast, KDE is
still KDE 2 in testing, which in good conscience I don't think we can
release with.

I'm hoping this can change soon, and my impression is that the situation
is beginning to improve.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: The IPsec kernel problem

2003-10-02 Thread martin f krafft

also sprach Herbert Xu [EMAIL PROTECTED] [2003.10.03.0121 +0200]:
 I have given you the reason for this many times already.  Please
 reread the thread on debian-devel carefully.

This one post did in fact slip my eyes. In it, you mention some
checks when it comes to patch inclusion.

I have a particular problem with:

  * If it's a feature, can it be disabled/enabled at runtime?

Sinec we're making generic kernels, this is a must.  The presence
of the patch should not prevent me from doing something that I would
otherwise be able to do.

I cannot disable IPsec at runtime as I cannot replace the IP stack
at runtime, and it modifies the IP stack. Moreover, you state the
reason why you should not put IPsec in the kernel right there: The
presence of the patch should not prevent me from doing something
that I would otherwise be able to do. Well, it does.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpj2vhMdpnhL.pgp
Description: PGP signature

Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)

2003-10-02 Thread Nathanael Nerode

Well, aptitude is certainly better than it used to be.

At least now it's keystroke-compatible with dselect.  I still find it
less useful though.  :-P

--
Although aptitude uses only one fewer line of screen space for the
list of packages, somehow it manages to have less information.  The
absence of priority information is unpleasant to say the least.

In trying to get it to show priorities, I discovered that the options for
changing display formats are completely cryptic; on
my machine I see:
The default grouping method for pacakge viewsr)
 The default display-limit for package views
The display format for package views %c%a%M %p #%v%V
   The display format for the status line%d
   The display format for the header line%N %n #%B %u %o

Some investigation indicates that r) is the end of a long
configuration line.  That and the others are eventually documented deep
in the User's Manual.  It would be nice if the default was verbose enough
that I didn't have to go all out and learn how to write my own.  :-P

--
When packages are selected to be installed by default as the
result of a manually selected package, I get to see and adjust the list
before going ahead with the download  install.  Unfortunately, I *don't*
get to see whether the packages are being selected because they are actually
depended upon, or whether they're Recommended, or whether they're
Suggested.  I suppose I could examine each package with 'i' *first*

There's no easy way to get the dselect behavior of These are recommended,
these are suggested.  Which do you want? -- which is what I like.

--
Figuring out how to tell aptitude not to automatically delete unused packages
required reading the User Manual while knowing that this was an issue.

This is on by default, and the information about marking a package
manually selected or not does not immediately spring to mind as having
anything to do with whether a package is unused or not.

Perhaps if it said Remove unused automatically-installed packages
automatically ?  ;-)

--
The Users Manual starts with a section on the non-interactive interface.
Huh?

--
Upon hitting 'g' without having done much, aptitude blanked out both sections
of the screen mysteriously.  I eventually figured out that I needed to
go to 'Views' and pick 'Next'.  Huh?

--
Under Tasks, if 'tasksel' is uninstalled, the one and only subcategory is
Unrecognized tasks.  Huh?

--
The menu is critical to dealing with many of aptitude's, um, issues.
However, you have to hit F10 to get it.  Which is usually OK, but if you're
connected through ssh from something which can't do better than a vt100
terminal, you're screwed.

Recent versions of dselect are pretty bad in this environment too
(switching into messed-up alternate character sets) but it used to work.
*sigh*

--
Eventually I found aptitude's Dselect theme, which helped some.

I guess aptitude could be made the recommended default package manager,
but I would hope that:
1.  Something more closely approximating the Dselect theme is used by
default, so that dselect users don't get utterly lost.
2.  Remove unused packages automatically is (a) better described and
  (b) off by default.
3. An alternate 'menu' key is provided which doesn't require an F10 key.

-- 
Nathanael Nerode  neroden at gcc.gnu.org
http://home.twcny.rr.com/nerode/neroden/fdl.html

Re: Which packages will hold up the release?

On Thu, Oct 02, 2003 at 10:43:24PM +0200, Björn Stenberg wrote:
 Steve Langasek wrote:
  What's hard to see at a glance is how large collections of packages are
  interrelated in their dependencies.  Many packages that you *don't* use
  may be having a direct effect on the packages you *do* use as a result
  of their bugginess.  I'd like to be able to make as much of this
  information as possible available to developers, so they can dig into
  some of the larger package knots according to their interests rather
  than it being exclusively the domain of the RM  assistants.

 I'm interested in helping with this. My why is X not in testing yet 
 script attempts to identify some hot spots, in the form of a few crude 
 toplists:

   http://bjorn.haxx.se/debian/toplist.html
   http://bjorn.haxx.se/debian/stalls.html

Yes, I refer to these lists frequently. :)  Thanks for putting these
together!

 The first sorts packages according to which package has the highest 
 number of other packages directly depend on it. Top-3: python2.3, 
 kdelibs, qt-x11-free.

 The second sorts packages according to which package stalls the 
 greatest number of other packages, via dependencies in more than one 
 level. Top-3: python2.3, libxml2 and libxslt.

Yep, and libxml2 is also a dependency of libxslt.  But of course,
neither of these are packages that need direct attention; the one is
held up waiting for the other, which is only waiting because it's too
young.  It's the related packages that need to be examined and put in
order (by removals or NMUs), and there's no good way to figure out right
now which packages those are, short of digging through the dependency
tree (or running simulations).

 I'd appreciate ideas and suggestions how to improve this and create 
 other information digests that can help developers find and choose 
 areas to work on.

Well, if you want to write a script that can trawl the dependency graphs
and identify work-needed packages within a cluster... :)

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Where are we now? (Was: Bits from the RM)

On Thu, Oct 02, 2003 at 05:57:58AM +0100, Scott James Remnant [EMAIL 
PROTECTED] was heard to say:
 I think it's fair to say that we're not going to reach the following
 state within 14 days unless a miracle, or a hell of a lot of work
 happens:

  I don't know about anyone else, but if we manage to end up 14 days
behind, I'd say that the new approach to release schedules is a
resounding success.  Woody was pushed back by how many months?

  (which isn't to say we can't try to do better, just injecting a bit of
   perspective)

  Daniel

-- 
/ Daniel Burrows [EMAIL PROTECTED] ---\
|If you want a picture of the future, imagine a boot |
| stamping on a human face -- forever. -- 1984   |
\ Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/

Re: Re: Where are we now? (Was: Bits from the RM)

  Hi,

  aptitude has a lot of problems that I don't have enough time to fix,
but I would appreciate it if people would confine themselves to the
facts when criticizing it.

On Thu, Oct 02, 2003 at 04:10:21PM -0500, Chris Cheney [EMAIL PROTECTED] was 
heard to say:
 On Thu, Oct 02, 2003 at 08:31:08PM +0200, Robert Lemmen wrote:
  On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote:
   Please don't do this yet, since dselect is still more self-documenting, 
   and therefore easier for new people to use.  :-P
  
  please do! dselect (whil ebeing verty simple and functional) has the
  most counter-intuitive user interface i have seen. the day i discovered
  aptitude and got rid of dselect meant a big step forward for my persoanl
  debian experience.
 
 From what I have heard about aptitude it has the fun side effect of
 removing packages that it thinks you didn't purposely install.

  It only thinks you didn't purposely install something if it was
pulled in purely through dependencies, and you can manually reset its
notion of whether something was automatically installed at any time.
  It also explicitly lists packages being removed for this reason, and
you can turn this behavior off if you want.

  Also
 aptitude's sort function was more user unfriendly than dselect by far
 (just hit 'o').  I happen to use the sort option in dselect often. If
 aptitude can be used as dselect is now, eg hit 'g' to download just
 standard it will be ok I suppose.

  That's true.

 I also don't think it is a particularly good idea for aptitude to
 default to installing suggests since it will likely bloat systems quite
 a bit installing various things such as bash-doc, gpart, parted, etc.

  aptitude doesn't depend on any of those.  Do you mean when installing
other packages?  If too much stuff is being pulled in from Recommends,
the package maintainers are using Recommends incorrectly.  I haven't
found this to be a problem in practice.

 Also, it will automatically install packages in non-free (when user has
 non-free listed) since packages in main are allowed to suggest non-free.

  aptitude installs Recommendations by default because this is what
Recommandations mean.  It does not install Suggestions because
Suggestions are not meant to be installed by default.  If you are
installing packages from contrib (which can Recommend and even Depend on
stuff in non-free), you should expect to get non-free stuff on your system.

  Daniel

-- 
/ Daniel Burrows [EMAIL PROTECTED] ---\
|  Put no trust in cryptic comments.  |
\ Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/

Re: Where are we now? (Was: Bits from the RM)

2003-10-02 Thread Andrew Suffield

On Thu, Oct 02, 2003 at 10:38:18PM +1000, Matthew Palmer wrote:
 On Thu, Oct 02, 2003 at 01:22:34PM +0100, Rob Bradford wrote:
  be fun though. I'm planning to only support upgrades from potato and
  woody. So that means i can remove all the cruft about upgrading from
 
 I was under the impression (don't ask me how; perhaps my mind came up with
 it on it's own) that we only supported stable-stable+1 upgrades...
 
 Obviously not.  Can anyone point me to a comprehensive rationale why not?

Mindless optimism. If you try skipping a release on a box with a fair
amount of stuff installed, expect to spend all day fixing it.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- --  |


signature.asc
Description: Digital signature

Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)

  As I indicated in a recent message, I don't currently have time to
get aptitude working the way I'd like.  Please consider this a public
call for a codeveloper -- you can interview by submitting working
patches for one of the issues below, particularly the ones I've outlined
a fix for.  (aptitude is maintained as an Alioth project, so if you have
an Alioth account, I can just add you to the project)

  I've added notes on immediate and long-term solutions to some of these
issues below, tagged as [development note].  If no-one takes me up on
this, which history would indicate is likely, this will make a nice TODO
list anyway :)

On Thu, Oct 02, 2003 at 07:43:37PM -0400, Nathanael Nerode [EMAIL PROTECTED] 
was heard to say:
 Although aptitude uses only one fewer line of screen space for the
 list of packages, somehow it manages to have less information.  The
 absence of priority information is unpleasant to say the least.

  Priority information isn't shown because I felt it would clutter up
the screen, and I for one never used that information anyway.  It will
never be visible by default.

 In trying to get it to show priorities, I discovered that the options for
 changing display formats are completely cryptic; on
 my machine I see:
 The default grouping method for pacakge viewsr)

  The r) should be a different color than the rest, which is why I've
never noticed this on my computer.  I suspect you're using a less
featureful terminal than standard xterm?

  [development note]
  In any event, this table needs some padding between the two columns.
This is a fairly simple fix, unless I forgot to implement inter-column
padding in vs_table, in which case it needs to be hacked in first.

  The default display-limit for package views
 The display format for package views %c%a%M %p #%v%V
The display format for the status line%d
The display format for the header line%N %n #%B %u %o

  [development note]

  This is a nice general method of configuration, but for many tasks
something like this would be better:

  View-
 Show/Hide column-
[X] Action
[X] Package name
...

  An interesting problem would be to merge the two methods of
configuration.  The current method is much more flexible, but the design
makes it hard to reliably configure the columns based on a bunch of
boolean variables.  A new design or design changemight be needed: for
instance, only allow one column of each type (which makes some sense
anyway) and store a boolean vector indicating which columns are active.

 When packages are selected to be installed by default as the
 result of a manually selected package, I get to see and adjust the list
 before going ahead with the download  install.  Unfortunately, I *don't*
 get to see whether the packages are being selected because they are actually
 depended upon, or whether they're Recommended, or whether they're
 Suggested.

  [development note]

  Code to determine this is in cmdline.cc.  To move it to the UI:

  (a) move it somewhere under generic/
  (b) figure out how to put its output into the preview screen.
  A reasonable first try is to put it in the lower half of the
  screen, where the package description is by default.

  One approach to this is to make the lower half of the screen
  switchable (using a vs_multiplexer) and to bind some key to switch
  it.  I think this may already be done in order to allow tag
  databases to be edited.
  
  Then, add a new page to the multiplexer which is visible by
  default and shows extended information about why the currently
  selected package is in its current state.  This infrastructure
  could also be used to show package info in the lower half like
  dselect does, eventually (but maybe a modifiable form like the
  aptitude info screen)

  See how package descriptions work in the code for more
  information.

 There's no easy way to get the dselect behavior of These are recommended,
 these are suggested.  Which do you want? -- which is what I like.

  [development note]

  It might be a good idea to add a tree for suggested but not selected
packages to the preview screen.  This tree should be collapsed by
default.

 Figuring out how to tell aptitude not to automatically delete unused 
 packages
 required reading the User Manual while knowing that this was an issue.
 
 This is on by default, and the information about marking a package
 manually selected or not does not immediately spring to mind as having
 anything to do with whether a package is unused or not.

 Perhaps if it said Remove unused automatically-installed packages
 automatically ?  ;-)

  In most cases, the garbage collection should operate without you
needing to know about it.  (the increasing prevalence of meta-packages
is making this a bit tricky -- some explicit marking of these beasts in
the package tags might be nice)

  If you have a problem, it's likely because

Re: Re: Where are we now? (Was: Bits from the RM)

On Thu, Oct 02, 2003 at 10:09:16PM -0400, Daniel Burrows wrote:
 On Thu, Oct 02, 2003 at 04:10:21PM -0500, Chris Cheney [EMAIL PROTECTED] 
 was heard to say:
  I also don't think it is a particularly good idea for aptitude to
  default to installing suggests since it will likely bloat systems quite
  a bit installing various things such as bash-doc, gpart, parted, etc.
 
   aptitude doesn't depend on any of those.  Do you mean when installing
 other packages?  If too much stuff is being pulled in from Recommends,
 the package maintainers are using Recommends incorrectly.  I haven't
 found this to be a problem in practice.

I meant since aptitude defaults to installing suggests by default, there
are packages in standard and above that suggests many things that a
normal user would not really care to have installed. I just installed
aptitude on my system today to see how it works now (I hadn't looked it
in several months) and noticed all the options under Options-Dependency
Handling all the options were X'd which means selected right? I can't
paste it here since aptitude seems to have mouse support so copy/paste
doesn't work.

  Also, it will automatically install packages in non-free (when user has
  non-free listed) since packages in main are allowed to suggest non-free.
 
   aptitude installs Recommendations by default because this is what
 Recommandations mean.  It does not install Suggestions because
 Suggestions are not meant to be installed by default.  If you are
 installing packages from contrib (which can Recommend and even Depend on
 stuff in non-free), you should expect to get non-free stuff on your system.

As stated above aptitude does apparently now default to

'[X] Install Suggested packages automatically'

as well. As I did not turn it on myself and I even removed ~/.aptitude
several times to verify it was still enabled.

Chris


signature.asc
Description: Digital signature

Re: Re: Where are we now? (Was: Bits from the RM)

On Thu, Oct 02, 2003 at 09:59:58PM -0500, Chris Cheney [EMAIL PROTECTED] was 
heard to say:
 On Thu, Oct 02, 2003 at 10:09:16PM -0400, Daniel Burrows wrote:
  On Thu, Oct 02, 2003 at 04:10:21PM -0500, Chris Cheney [EMAIL PROTECTED] 
  was heard to say:
   I also don't think it is a particularly good idea for aptitude to
   default to installing suggests since it will likely bloat systems quite
   a bit installing various things such as bash-doc, gpart, parted, etc.
  
aptitude doesn't depend on any of those.  Do you mean when installing
  other packages?  If too much stuff is being pulled in from Recommends,
  the package maintainers are using Recommends incorrectly.  I haven't
  found this to be a problem in practice.
 
 I meant since aptitude defaults to installing suggests by default, there

  Hm, it does.  I thought I fixed that ages ago.

  Just for some background: this wasn't supposed to happen, because
turning suggests on is a really bad idea, but I apparently accidentally
set it to true in one place in the code and false in another place
and in the documentation.  I thought I fixed this at one point in the
past, but apparently not.

  What happens is that the default state is actually false, but if
you go to the preferences dialog, the preferences dialog shows that it's
selected and selecting Ok causes the setting to be changed.

 Handling all the options were X'd which means selected right? I can't
 paste it here since aptitude seems to have mouse support so copy/paste
 doesn't work.

  Just FYI, you can use Shift to override mouse support in programs.

  Daniel

-- 
/ Daniel Burrows [EMAIL PROTECTED] ---\
|   It is very dark.  If you proceed you are likely to be eaten by a grue.|
\--- (if (not (understand-this)) (go-to http://www.schemers.org)) /

Accepted mozilla-snapshot 0.0.20031002.13.trunk-1 (i386 source)

2003-10-02 Thread Takuo KITAME

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 02 Oct 2003 13:53:11 +0900
Source: mozilla-snapshot
Binary: mozilla-dom-inspector-snapshot mozilla-js-debugger-snapshot 
mozilla-mailnews-snapshot libnss-snapshot-dev mozilla-chatzilla-snapshot 
mozilla-psm-snapshot libnss-snapshot3 libnspr-snapshot-dev mozilla-snapshot-dev 
mozilla-browser-snapshot mozilla-snapshot libnspr-snapshot4
Architecture: source i386
Version: 0.0.20031002.13.trunk-1
Distribution: unstable
Urgency: low
Maintainer: Takuo KITAME [EMAIL PROTECTED]
Changed-By: Takuo KITAME [EMAIL PROTECTED]
Description: 
 libnspr-snapshot-dev - Netscape Portable Runtime library - development files (CVS 
snapsh
 libnspr-snapshot4 - Netscape Portable Runtime library (CVS snapshot)
 libnss-snapshot-dev - Netscape Security Libraries - development (CVS snapshot)
 libnss-snapshot3 - Netscape Security Libraries - runtime (CVS snapshot)
 mozilla-browser-snapshot - An Open Source WWW browser for X and GTK+ (CVS snapshot)
 mozilla-chatzilla-snapshot - IRC client written for mozilla (CVS snapshot)
 mozilla-dom-inspector-snapshot - A tool for inspecting the DOM of pages in Mozilla. 
(CVS snapshot)
 mozilla-js-debugger-snapshot - JavaScript debugger for use with Mozilla (CVS snapshot)
 mozilla-mailnews-snapshot - Mozilla-based mail system (CVS snapshot)
 mozilla-psm-snapshot - PSM - Personal Security Manager for Mozilla Browser (CVS 
snapshot
 mozilla-snapshot - An Open Source web browser for X [meta package] (CVS snapshot)
 mozilla-snapshot-dev - Header files for Mozilla development (CVS snapshot)
Closes: 209400
Changes: 
 mozilla-snapshot (0.0.20031002.13.trunk-1) unstable; urgency=low
 .
   * CVS update (trunk)
   * build-depends on autoconf2.13 (closes: #209400)
Files: 
 d1c90bd05beb737961e2f20bc83e0b54 1180 web extra 
mozilla-snapshot_0.0.20031002.13.trunk-1.dsc
 860822d634f4591c3bbcaae868aedda5 29664368 web extra 
mozilla-snapshot_0.0.20031002.13.trunk.orig.tar.gz
 2d51067fcff2b0661227d959f15f09d9 210935 web extra 
mozilla-snapshot_0.0.20031002.13.trunk-1.diff.gz
 f61850f0197d2b2579f6cdb9018de3ca 812 web extra 
mozilla-snapshot_0.0.20031002.13.trunk-1_i386.deb
 562d489cf564e31b08cff6df1356af17 10459498 web extra 
mozilla-browser-snapshot_0.0.20031002.13.trunk-1_i386.deb
 d2547a2526202a1a307810b0127bd3bd 296962 web extra 
mozilla-psm-snapshot_0.0.20031002.13.trunk-1_i386.deb
 ba91565792b63ad8af3ad6f9f46bab4b 2067256 mail extra 
mozilla-mailnews-snapshot_0.0.20031002.13.trunk-1_i386.deb
 5d3fb328102e619ef2da13a77272b067 141552 net extra 
mozilla-chatzilla-snapshot_0.0.20031002.13.trunk-1_i386.deb
 5cf523c4779fb8102f716f2591188ee7 3123480 devel extra 
mozilla-snapshot-dev_0.0.20031002.13.trunk-1_i386.deb
 d7d36911ede84aaa2b396a7178fa3f72 105048 libs extra 
libnspr-snapshot4_0.0.20031002.13.trunk-1_i386.deb
 fd654184ddd244ccda11451aa6293c79 167212 devel extra 
libnspr-snapshot-dev_0.0.20031002.13.trunk-1_i386.deb
 ce5ff103b149041f51f115d8f1aa5d84 2654 devel extra 
libnss-snapshot-dev_0.0.20031002.13.trunk-1_i386.deb
 b1c77aec0d80afd30d99ca6489aeacdb 538386 libs extra 
libnss-snapshot3_0.0.20031002.13.trunk-1_i386.deb
 197cb03e370c9e5b28ea6f08ad706b86 207620 devel extra 
mozilla-js-debugger-snapshot_0.0.20031002.13.trunk-1_i386.deb
 0388cfd5359156cc9b25f1f87bdf472f 128968 web extra 
mozilla-dom-inspector-snapshot_0.0.20031002.13.trunk-1_i386.deb

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

iD8DBQE/e8ANU+WZW1FVMwoRApFBAJwKboUuN8uj/5XcEaAgHKJbXQ87PwCfYWO9
pTmlI0EDFaI2RjmuEhvydn8=
=4+iC
-END PGP SIGNATURE-


Accepted:
libnspr-snapshot-dev_0.0.20031002.13.trunk-1_i386.deb
  to pool/main/m/mozilla-snapshot/libnspr-snapshot-dev_0.0.20031002.13.trunk-1_i386.deb
libnspr-snapshot4_0.0.20031002.13.trunk-1_i386.deb
  to pool/main/m/mozilla-snapshot/libnspr-snapshot4_0.0.20031002.13.trunk-1_i386.deb
libnss-snapshot-dev_0.0.20031002.13.trunk-1_i386.deb
  to pool/main/m/mozilla-snapshot/libnss-snapshot-dev_0.0.20031002.13.trunk-1_i386.deb
libnss-snapshot3_0.0.20031002.13.trunk-1_i386.deb
  to pool/main/m/mozilla-snapshot/libnss-snapshot3_0.0.20031002.13.trunk-1_i386.deb
mozilla-browser-snapshot_0.0.20031002.13.trunk-1_i386.deb
  to 
pool/main/m/mozilla-snapshot/mozilla-browser-snapshot_0.0.20031002.13.trunk-1_i386.deb
mozilla-chatzilla-snapshot_0.0.20031002.13.trunk-1_i386.deb
  to 
pool/main/m/mozilla-snapshot/mozilla-chatzilla-snapshot_0.0.20031002.13.trunk-1_i386.deb
mozilla-dom-inspector-snapshot_0.0.20031002.13.trunk-1_i386.deb
  to 
pool/main/m/mozilla-snapshot/mozilla-dom-inspector-snapshot_0.0.20031002.13.trunk-1_i386.deb
mozilla-js-debugger-snapshot_0.0.20031002.13.trunk-1_i386.deb
  to 
pool/main/m/mozilla-snapshot/mozilla-js-debugger-snapshot_0.0.20031002.13.trunk-1_i386.deb
mozilla-mailnews-snapshot_0.0.20031002.13.trunk-1_i386.deb
  to 
pool/main/m/mozilla-snapshot/mozilla-mailnews-snapshot_0.0.20031002.13.trunk-1_i386.deb
mozilla-psm-snapshot_0.0.20031002.13.trunk-1_i386.deb
  to

Accepted gnustep-make 1.8.0-1 (i386 source all)

2003-10-02 Thread doko

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 30 Sep 2003 01:52:27 +0200
Source: gnustep-make
Binary: gnustep-make gnustep-make-doc
Architecture: source i386 all
Version: 1.8.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian GNUstep maintainers [EMAIL PROTECTED]
Changed-By: [EMAIL PROTECTED]
Description: 
 gnustep-make - Basic GNUstep Scripts and Makefiles
 gnustep-make-doc - Documentation for GNUstep-make
Changes: 
 gnustep-make (1.8.0-1) unstable; urgency=low
 .
   * New upstream release.
   * debian/rules : update V_OBJC (3:3.3-1 - 4:3.3.1).
   * Update README.Debian.
Files: 
 dbe37edc1d38fa486fe07c760c9a4b69 820 libs optional gnustep-make_1.8.0-1.dsc
 a2c7752787ecb77e34062e86cc3f18ce 357513 libs optional gnustep-make_1.8.0.orig.tar.gz
 ff2952d5378ea91cd0c53f17493148e3 8701 libs optional gnustep-make_1.8.0-1.diff.gz
 41ecc6d1d2452255f46e399ab42fe762 143326 libs optional gnustep-make_1.8.0-1_i386.deb
 06128b7f6092801e2d7fcf6285f3a855 135664 doc optional gnustep-make-doc_1.8.0-1_all.deb

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

iD8DBQE/e76JStlRaw+TLJwRAsv9AJ9QAbYny41/GlBZ94uGE/JLQkC+PwCeMWvH
+1rAStmIPytiZZKTAyPK+NE=
=RQYP
-END PGP SIGNATURE-


Accepted:
gnustep-make-doc_1.8.0-1_all.deb
  to pool/main/g/gnustep-make/gnustep-make-doc_1.8.0-1_all.deb
gnustep-make_1.8.0-1.diff.gz
  to pool/main/g/gnustep-make/gnustep-make_1.8.0-1.diff.gz
gnustep-make_1.8.0-1.dsc
  to pool/main/g/gnustep-make/gnustep-make_1.8.0-1.dsc
gnustep-make_1.8.0-1_i386.deb
  to pool/main/g/gnustep-make/gnustep-make_1.8.0-1_i386.deb
gnustep-make_1.8.0.orig.tar.gz
  to pool/main/g/gnustep-make/gnustep-make_1.8.0.orig.tar.gz


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

Accepted debootstrap 0.2.8 (i386 source)

2003-10-02 Thread J.H.M. Dassen (Ray)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 07:57:16 +0200
Source: debootstrap
Binary: debootstrap-udeb debootstrap
Architecture: source i386
Version: 0.2.8
Distribution: unstable
Urgency: high
Maintainer: J.H.M. Dassen (Ray) [EMAIL PROTECTED]
Changed-By: J.H.M. Dassen (Ray) [EMAIL PROTECTED]
Description: 
 debootstrap - Bootstrap a basic Debian system
 debootstrap-udeb - Bootstrap the Debian system (udeb)
Changes: 
 debootstrap (0.2.8) unstable; urgency=high
 .
   * [sid] Added libtextwrap1 for tasksel; removed libsasl2 as it is no longer
 needed.
Files: 
 3a8649c26a07c20e099d5e387c730e59 884 admin required debootstrap_0.2.8.dsc
 a8b95bfb557fe799b715d49db344ea10 26824 admin required debootstrap_0.2.8.tar.gz
 b9a43e8f601be1aa152864d87a851189 43256 debian-installer required 
debootstrap-udeb_0.2.8_i386.udeb
 bb4dc97828b3b96bf6aae4c176e3125f 58420 admin extra debootstrap_0.2.8_i386.deb

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

iQEXAwUBP3u/sQxJU8feGmjHFAKFxQQAs+sz9FHQij1w5WvN3zbou9CaDTOHv/x3
HqOBNEF+yaNCXfOOAeqGybCl5rdqP8BA7FB46DK1Tsgh9uW5d/RJD/vYxE6ChKce
ti716paMv5D/MtLZUaHox5DHoyK1Ps67AbVKNcYI7VrX5xjiDkTR8Ltzk96OZz05
5ZaqB/93g2oD/ApwIX7AwdK5ia9GvVHUhZGoru5A906r8bPtTRDEki0vEQi6UXWJ
FHMWjDGgowDWS02e5nri8FPUCpYjD5sNySkl3pZ/C1/kem9fF9fqt/2uj71BHQvL
liQ7iXiORFACFiRiImoIot+njJqvwIg7hrQCWauJIlvZZnSqOoyyj2Sw
=6RNs
-END PGP SIGNATURE-


Accepted:
debootstrap-udeb_0.2.8_i386.udeb
  to pool/main/d/debootstrap/debootstrap-udeb_0.2.8_i386.udeb
debootstrap_0.2.8.dsc
  to pool/main/d/debootstrap/debootstrap_0.2.8.dsc
debootstrap_0.2.8.tar.gz
  to pool/main/d/debootstrap/debootstrap_0.2.8.tar.gz
debootstrap_0.2.8_i386.deb
  to pool/main/d/debootstrap/debootstrap_0.2.8_i386.deb


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

Accepted lablgl 0.99-16 (i386 source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  1 Oct 2003 16:15:29 +0200
Source: lablgl
Binary: liblablgl-ocaml-dev liblablgl-ocaml
Architecture: source i386
Version: 0.99-16
Distribution: unstable
Urgency: low
Maintainer: Sven Luther [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description: 
 liblablgl-ocaml - Runtime libraries for lablgl
 liblablgl-ocaml-dev - an OpenGL interface for Objective Caml
Changes: 
 lablgl (0.99-16) unstable; urgency=low
 .
   * Rebuilt for ocaml 3.07.
Files: 
 31569e7fbf90c1d32b441e190cb05bac 758 devel optional lablgl_0.99-16.dsc
 295e3936eeaed2d210d28efa638c1451 6027 devel optional lablgl_0.99-16.diff.gz
 0d475c948307741b54127a4e9f46f55a 40550 devel optional liblablgl-ocaml_0.99-16_i386.deb
 b9c52c95cde81136f531ddfca4051f25 392028 devel optional 
liblablgl-ocaml-dev_0.99-16_i386.deb

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

iD8DBQE/e8vY2WTeT3CRQaQRArhhAJ0cJAbK5PQlIMI7kTljrWvMbfrjKwCghdVt
4wVHFpCznQdi7UbH5gRTOQE=
=/b9H
-END PGP SIGNATURE-


Accepted:
lablgl_0.99-16.diff.gz
  to pool/main/l/lablgl/lablgl_0.99-16.diff.gz
lablgl_0.99-16.dsc
  to pool/main/l/lablgl/lablgl_0.99-16.dsc
liblablgl-ocaml-dev_0.99-16_i386.deb
  to pool/main/l/lablgl/liblablgl-ocaml-dev_0.99-16_i386.deb
liblablgl-ocaml_0.99-16_i386.deb
  to pool/main/l/lablgl/liblablgl-ocaml_0.99-16_i386.deb


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

Accepted conglomerate 0.7.4-1 (i386 source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  1 Oct 2003 17:37:46 +0200
Source: conglomerate
Binary: conglomerate
Architecture: source i386
Version: 0.7.4-1
Distribution: unstable
Urgency: low
Maintainer: Geert Stappers [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description: 
 conglomerate - userfriendly XML editor
Changes: 
 conglomerate (0.7.4-1) unstable; urgency=low
 .
   * New upstream release.
Files: 
 a3a0012aaad39d40d5980294e72b0deb 768 editors optional conglomerate_0.7.4-1.dsc
 90acc05143bcce4f7108fbe6669c82f0 846534 editors optional 
conglomerate_0.7.4.orig.tar.gz
 6f4451545b7dd51a63a1e2b23eb49b9a 9466 editors optional conglomerate_0.7.4-1.diff.gz
 f6d31e07bb1f41d2e1fbac29ab9932b1 387260 editors optional conglomerate_0.7.4-1_i386.deb

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

iD8DBQE/e8rl2WTeT3CRQaQRAkvdAJsEhBWjUSBoqvUct5QU3D3bzsh7pQCfdUYe
9wrSAmVxVAhRjRsklvzyptA=
=hEgM
-END PGP SIGNATURE-


Accepted:
conglomerate_0.7.4-1.diff.gz
  to pool/main/c/conglomerate/conglomerate_0.7.4-1.diff.gz
conglomerate_0.7.4-1.dsc
  to pool/main/c/conglomerate/conglomerate_0.7.4-1.dsc
conglomerate_0.7.4-1_i386.deb
  to pool/main/c/conglomerate/conglomerate_0.7.4-1_i386.deb
conglomerate_0.7.4.orig.tar.gz
  to pool/main/c/conglomerate/conglomerate_0.7.4.orig.tar.gz


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

Accepted lablgtk 1.2.5-10 (i386 source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  1 Oct 2003 16:38:26 +0200
Source: lablgtk
Binary: liblablgtk-ocaml liblablgtk-ocaml-dev
Architecture: source i386
Version: 1.2.5-10
Distribution: unstable
Urgency: low
Maintainer: Sven Luther [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description: 
 liblablgtk-ocaml - Runtime libraries for lablgtk.
 liblablgtk-ocaml-dev - Ocaml bindings to Gtk+
Changes: 
 lablgtk (1.2.5-10) unstable; urgency=low
 .
   * Rebuilt for ocaml 3.07.
Files: 
 acd817e2168165eddb1c5b7e1aef5554 774 devel optional lablgtk_1.2.5-10.dsc
 a56aff7d7f05bf563793c49582d9a437 9766 devel optional lablgtk_1.2.5-10.diff.gz
 f71ccd25cc681f93570ff4a626a9 86738 devel optional 
liblablgtk-ocaml_1.2.5-10_i386.deb
 8c132826ff7dd50683aa498b2313f569 1892932 devel optional 
liblablgtk-ocaml-dev_1.2.5-10_i386.deb

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

iD8DBQE/e8yY2WTeT3CRQaQRAvObAJ9JQjBa8/1ZMHTXDh1axYfstDb7aACfX1sU
xCO0qtkadju5JQ9BtYDnbi4=
=r/Qq
-END PGP SIGNATURE-


Accepted:
lablgtk_1.2.5-10.diff.gz
  to pool/main/l/lablgtk/lablgtk_1.2.5-10.diff.gz
lablgtk_1.2.5-10.dsc
  to pool/main/l/lablgtk/lablgtk_1.2.5-10.dsc
liblablgtk-ocaml-dev_1.2.5-10_i386.deb
  to pool/main/l/lablgtk/liblablgtk-ocaml-dev_1.2.5-10_i386.deb
liblablgtk-ocaml_1.2.5-10_i386.deb
  to pool/main/l/lablgtk/liblablgtk-ocaml_1.2.5-10_i386.deb


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

Accepted lablgtk2 0.beta.20030828-1 (i386 source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  1 Oct 2003 17:01:51 +0200
Source: lablgtk2
Binary: liblablgtk2-ocaml liblablgtk2-ocaml-dev
Architecture: source i386
Version: 0.beta.20030828-1
Distribution: unstable
Urgency: low
Maintainer: Sven Luther [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description: 
 liblablgtk2-ocaml - Runtime libraries for ocaml bindings for Gtk+ version 2
 liblablgtk2-ocaml-dev - Ocaml bindings to Gtk+ version 2
Changes: 
 lablgtk2 (0.beta.20030828-1) unstable; urgency=low
 .
   * New upstream release
   * Rebuilt for ocaml 3.07.
Files: 
 4529447de0b33c1a9ef6d89b91b84d02 774 libdevel optional lablgtk2_0.beta.20030828-1.dsc
 426e7ae9bd4c3ea538dcab11934017a1 582644 libdevel optional 
lablgtk2_0.beta.20030828.orig.tar.gz
 0c737c29e006427fc316c13be2dd9051 14983 libdevel optional 
lablgtk2_0.beta.20030828-1.diff.gz
 6c3e84c8f47c78a615253f056f66af4a 117906 libs optional 
liblablgtk2-ocaml_0.beta.20030828-1_i386.deb
 57e8d09afadd311c1701581d838e13b2 1986744 libdevel optional 
liblablgtk2-ocaml-dev_0.beta.20030828-1_i386.deb

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

iD8DBQE/e84I2WTeT3CRQaQRAjUUAKCQq5FFVswkMiDwQU+1yswWPLdi8gCfSScV
aULp5iCjhgXxplybv7/EjFo=
=Fs5V
-END PGP SIGNATURE-


Accepted:
lablgtk2_0.beta.20030828-1.diff.gz
  to pool/main/l/lablgtk2/lablgtk2_0.beta.20030828-1.diff.gz
lablgtk2_0.beta.20030828-1.dsc
  to pool/main/l/lablgtk2/lablgtk2_0.beta.20030828-1.dsc
lablgtk2_0.beta.20030828.orig.tar.gz
  to pool/main/l/lablgtk2/lablgtk2_0.beta.20030828.orig.tar.gz
liblablgtk2-ocaml-dev_0.beta.20030828-1_i386.deb
  to pool/main/l/lablgtk2/liblablgtk2-ocaml-dev_0.beta.20030828-1_i386.deb
liblablgtk2-ocaml_0.beta.20030828-1_i386.deb
  to pool/main/l/lablgtk2/liblablgtk2-ocaml_0.beta.20030828-1_i386.deb


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

Accepted camlzip 1.01-10 (i386 source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  1 Oct 2003 17:31:51 +0200
Source: camlzip
Binary: libzip-ocaml libzip-ocaml-dev
Architecture: source i386
Version: 1.01-10
Distribution: unstable
Urgency: low
Maintainer: Sven Luther [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description: 
 libzip-ocaml - ocaml compression libraries
 libzip-ocaml-dev - ocaml compression libraries
Changes: 
 camlzip (1.01-10) unstable; urgency=low
 .
   * Rebuilt for ocaml 3.07.
Files: 
 0021b396daeccf6737e42bdb537128c7 622 devel optional camlzip_1.01-10.dsc
 962dad46ed1bdaddffa28fa087dee5dc 3216 devel optional camlzip_1.01-10.diff.gz
 ea655b14aa5621ed1f8a0cac3bca1b53 5904 libs optional libzip-ocaml_1.01-10_i386.deb
 1990778ba26449948277062169e3e6c9 72960 devel optional 
libzip-ocaml-dev_1.01-10_i386.deb

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

iD8DBQE/e9KK2WTeT3CRQaQRAv3AAJ9xlY/z6ZnxKIzuF8V7gUw1ALHQKgCeKich
OQVIjS2PPP1+WKGARWqbiSI=
=mF/R
-END PGP SIGNATURE-


Accepted:
camlzip_1.01-10.diff.gz
  to pool/main/c/camlzip/camlzip_1.01-10.diff.gz
camlzip_1.01-10.dsc
  to pool/main/c/camlzip/camlzip_1.01-10.dsc
libzip-ocaml-dev_1.01-10_i386.deb
  to pool/main/c/camlzip/libzip-ocaml-dev_1.01-10_i386.deb
libzip-ocaml_1.01-10_i386.deb
  to pool/main/c/camlzip/libzip-ocaml_1.01-10_i386.deb


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

Accepted hlins 0.39-3 (all source)

2003-10-02 Thread Ralf Treinen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  1 Oct 2003 22:46:20 +0200
Source: hlins
Binary: hlins
Architecture: source all
Version: 0.39-3
Distribution: unstable
Urgency: low
Maintainer: Debian OCaml Maintainers [EMAIL PROTECTED]
Changed-By: Ralf Treinen [EMAIL PROTECTED]
Description: 
 hlins  - Insert URLs into html documents
Changes: 
 hlins (0.39-3) unstable; urgency=low
 .
   * Standards-Version 3.6.1 (no change)
   * Build with ocaml-3.07.
   * Remove version from dependency on dpatch, we don't need it.
   * Upstream repository is now on alioth.debian.org.
   * Fix doc/examples/test-examples/Makefile to use the right hlins.
Files: 
 34592eea112b85055a69ba2cadd8a28e 788 text optional hlins_0.39-3.dsc
 f9d742c39577e3025f227975679e69f8 3156 text optional hlins_0.39-3.diff.gz
 feaa36193cdf051dc277d1fded85483d 50314 text optional hlins_0.39-3_all.deb

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

iD8DBQE/e9RItzWmSeC6BMERAlRgAJ4huyko6t+LBgVg/Z6alo7pXJmtGwCfUZdW
vFTNAz/m2kjIY6W210sXThY=
=YOvn
-END PGP SIGNATURE-


Accepted:
hlins_0.39-3.diff.gz
  to pool/main/h/hlins/hlins_0.39-3.diff.gz
hlins_0.39-3.dsc
  to pool/main/h/hlins/hlins_0.39-3.dsc
hlins_0.39-3_all.deb
  to pool/main/h/hlins/hlins_0.39-3_all.deb


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

Accepted mlgtk 2.0.0-11 (i386 source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  1 Oct 2003 17:19:35 +0200
Source: mlgtk
Binary: libmlgtk-ocaml-dev libmlgtk-ocaml
Architecture: source i386
Version: 2.0.0-11
Distribution: unstable
Urgency: low
Maintainer: Sven Luther [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description: 
 libmlgtk-ocaml - Ocaml bindings for Gtk+
 libmlgtk-ocaml-dev - Ocaml bindings for Gtk+
Changes: 
 mlgtk (2.0.0-11) unstable; urgency=low
 .
   * Rebuilt for ocaml 3.07.
Files: 
 0ce31b26f5f7904f1d416023be2dab19 644 libdevel optional mlgtk_2.0.0-11.dsc
 0bef5245de1c4d72e897a281a4931e82 13751 libdevel optional mlgtk_2.0.0-11.diff.gz
 04c009715557fe310597d79aa80af139 42546 libs optional libmlgtk-ocaml_2.0.0-11_i386.deb
 428fc49679a76526a119ec1a36e53f05 609576 libdevel optional 
libmlgtk-ocaml-dev_2.0.0-11_i386.deb

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

iD8DBQE/e9Q52WTeT3CRQaQRArdBAJ0bO4EfKH7Ge48HNTuNblaJMveRvQCeLcru
Z0+fVE5RffTDR6m4/kAkPr8=
=VGQI
-END PGP SIGNATURE-


Accepted:
libmlgtk-ocaml-dev_2.0.0-11_i386.deb
  to pool/main/m/mlgtk/libmlgtk-ocaml-dev_2.0.0-11_i386.deb
libmlgtk-ocaml_2.0.0-11_i386.deb
  to pool/main/m/mlgtk/libmlgtk-ocaml_2.0.0-11_i386.deb
mlgtk_2.0.0-11.diff.gz
  to pool/main/m/mlgtk/mlgtk_2.0.0-11.diff.gz
mlgtk_2.0.0-11.dsc
  to pool/main/m/mlgtk/mlgtk_2.0.0-11.dsc


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

Accepted ledit 1.11-2 (all source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 30 Sep 2003 22:39:31 +0200
Source: ledit
Binary: ledit
Architecture: source all
Version: 1.11-2
Distribution: unstable
Urgency: low
Maintainer: Sven Luther [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description: 
 ledit  - line editor for interactive programs
Changes: 
 ledit (1.11-2) unstable; urgency=low
 .
   * Rebuilt for ocaml 3.07.
Files: 
 debfbec0db0d63bdf542f131c701655f 560 editors optional ledit_1.11-2.dsc
 b71fa9ef0ae0cbabf66b22ded5268e72 3255 editors optional ledit_1.11-2.diff.gz
 0950e9f04e154ef975645afe 27078 editors optional ledit_1.11-2_all.deb

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

iD8DBQE/e9qW2WTeT3CRQaQRApUcAJ42BFNKoskjSlPqnkn3RTU5ZyOjrwCfWW8y
7DVcNSTp6uCz2oxzO68gJTc=
=VVQ4
-END PGP SIGNATURE-


Accepted:
ledit_1.11-2.diff.gz
  to pool/main/l/ledit/ledit_1.11-2.diff.gz
ledit_1.11-2.dsc
  to pool/main/l/ledit/ledit_1.11-2.dsc
ledit_1.11-2_all.deb
  to pool/main/l/ledit/ledit_1.11-2_all.deb


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

Accepted svn-devscripts 0.2 (all source)

2003-10-02 Thread Eduard Bloch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  1 Oct 2003 13:30:21 +0200
Source: svn-devscripts
Binary: svn-devscripts
Architecture: source all
Version: 0.2
Distribution: unstable
Urgency: low
Maintainer: Eduard Bloch [EMAIL PROTECTED]
Changed-By: Eduard Bloch [EMAIL PROTECTED]
Description: 
 svn-devscripts - helpers to maintain Debian packages with Subversion
Changes: 
 svn-devscripts (0.2) unstable; urgency=low
 .
   * s/Url/URL/ in svn-0.30 output, fixed parser where needed
   * documentation updates
Files: 
 d6030b478b232a6b4e7e30a0528b4dd6 511 devel extra svn-devscripts_0.2.dsc
 ae08aa8d9da90e788e9c96091f65c4cb 17884 devel extra svn-devscripts_0.2.tar.gz
 3408facc5bc3d4b5d3e9609c96b1362b 20258 devel extra svn-devscripts_0.2_all.deb

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

iD8DBQE/e9wT4QZIHu3wCMURAqgrAJ4wfZc29CpnIYsQeInd8GMAIpxk7QCfX8DX
nPuTr9jpFyh3/EQYA7URaxA=
=gMTm
-END PGP SIGNATURE-


Accepted:
svn-devscripts_0.2.dsc
  to pool/main/s/svn-devscripts/svn-devscripts_0.2.dsc
svn-devscripts_0.2.tar.gz
  to pool/main/s/svn-devscripts/svn-devscripts_0.2.tar.gz
svn-devscripts_0.2_all.deb
  to pool/main/s/svn-devscripts/svn-devscripts_0.2_all.deb


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

Accepted nkf 2.03-1 (i386 source)

2003-10-02 Thread NOKUBI Takatsugu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 15:22:51 +0900
Source: nkf
Binary: libnkf-perl nkf
Architecture: source i386
Version: 2.03-1
Distribution: unstable
Urgency: low
Maintainer: NOKUBI Takatsugu [EMAIL PROTECTED]
Changed-By: NOKUBI Takatsugu [EMAIL PROTECTED]
Description: 
 libnkf-perl - Network Kanji code conversion Filter for Perl
 nkf- Network Kanji code conversion Filter
Changes: 
 nkf (2.03-1) unstable; urgency=low
 .
   * New upstream release
Files: 
 de911430302ac250865688d0f55b037e 567 text optional nkf_2.03-1.dsc
 5c8c19bf00b40aaf51a2c8d72fccc1b2 106571 text optional nkf_2.03.orig.tar.gz
 42f260d3c100521dcb17fcb89adc6a9d 134975 text optional nkf_2.03-1.diff.gz
 400db26cc79a94c2376b52a952a3f059 75886 text optional nkf_2.03-1_i386.deb
 47fd1b2749846490dd1f0fdf6f4e1651 64072 text optional libnkf-perl_2.03-1_i386.deb

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

iD8DBQE/e+J6K6gmAsLOgJkRAsCmAJ0cqzUQb7PkdpW3Unr61U0KK+4cxwCgmDdM
vRfa5OpZ3O3tXlq+D7U9338=
=Qz3q
-END PGP SIGNATURE-


Accepted:
libnkf-perl_2.03-1_i386.deb
  to pool/main/n/nkf/libnkf-perl_2.03-1_i386.deb
nkf_2.03-1.diff.gz
  to pool/main/n/nkf/nkf_2.03-1.diff.gz
nkf_2.03-1.dsc
  to pool/main/n/nkf/nkf_2.03-1.dsc
nkf_2.03-1_i386.deb
  to pool/main/n/nkf/nkf_2.03-1_i386.deb
nkf_2.03.orig.tar.gz
  to pool/main/n/nkf/nkf_2.03.orig.tar.gz


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

Accepted spamoracle 1.3-2 (i386 source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed,  1 Oct 2003 17:37:52 +0200
Source: spamoracle
Binary: spamoracle spamoracle-byte
Architecture: source i386 all
Version: 1.3-2
Distribution: unstable
Urgency: low
Maintainer: Sven Luther [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description: 
 spamoracle - A statistical analysis spam filter based on Bayes' formula
 spamoracle-byte - A statistical analysis spam filter based on Bayes' formula
Changes: 
 spamoracle (1.3-2) unstable; urgency=low
 .
   * Rebuilt with ocaml 3.07.
Files: 
 bd33e34efc191929dd52bc8f0f101df8 594 net optional spamoracle_1.3-2.dsc
 139012792aa5dc2e1064827a34a25d59 3541 net optional spamoracle_1.3-2.diff.gz
 880ffae8eea6ddad1ebabb3841d09e8b 251128 net optional spamoracle-byte_1.3-2_all.deb
 d2ad053d239c4dc406e4d9354e38c40e 141036 net optional spamoracle_1.3-2_i386.deb

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

iD8DBQE/e+Ej2WTeT3CRQaQRAul0AJ9sMqUR7erRseEg0OLV+S8DHjKkBQCfbuZA
8Uof4g3rt4V7FuVkdlfTgBw=
=+QLm
-END PGP SIGNATURE-


Accepted:
spamoracle-byte_1.3-2_all.deb
  to pool/main/s/spamoracle/spamoracle-byte_1.3-2_all.deb
spamoracle_1.3-2.diff.gz
  to pool/main/s/spamoracle/spamoracle_1.3-2.diff.gz
spamoracle_1.3-2.dsc
  to pool/main/s/spamoracle/spamoracle_1.3-2.dsc
spamoracle_1.3-2_i386.deb
  to pool/main/s/spamoracle/spamoracle_1.3-2_i386.deb


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

Accepted erb 2.0.4-3 (all source)

2003-10-02 Thread akira yamada

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 17:41:23 +0900
Source: erb
Binary: liberb-ruby1.6
Architecture: source all
Version: 2.0.4-3
Distribution: unstable
Urgency: low
Maintainer: akira yamada [EMAIL PROTECTED]
Changed-By: akira yamada [EMAIL PROTECTED]
Description: 
 liberb-ruby1.6 - Tiny eRuby for Ruby 1.6
Closes: 209501 209501
Changes: 
 erb (2.0.4-3) unstable; urgency=low
 .
   * debian/control: improved description, closes: #209501, #209501. thanks to
 Javier Fernandez-Sanguino.
Files: 
 6612e6f41b509dd0baf11c80fb0ac6cb 576 interpreters optional erb_2.0.4-3.dsc
 6c2329f268b7dbbb92c3b392ab4fb8f8 3771 interpreters optional erb_2.0.4-3.diff.gz
 bc97af127d833a3eb533654f30e0d06b 8040 interpreters optional 
liberb-ruby1.6_2.0.4-3_all.deb

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

iD8DBQE/e+brXzkxpuIT8aARAoqOAJ9lM9O8yL8gGOeptvyOM0rInWD2zQCfcT56
GQ+ACNgs5OefnuT5lOlxfNA=
=v/wI
-END PGP SIGNATURE-


Accepted:
erb_2.0.4-3.diff.gz
  to pool/main/e/erb/erb_2.0.4-3.diff.gz
erb_2.0.4-3.dsc
  to pool/main/e/erb/erb_2.0.4-3.dsc
liberb-ruby1.6_2.0.4-3_all.deb
  to pool/main/e/erb/liberb-ruby1.6_2.0.4-3_all.deb


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

Accepted galeon 1.3.9-2 (source)

2003-10-02 Thread Mark Howard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 09:50:54 +0100
Source: galeon
Binary: galeon
Architecture: source
Version: 1.3.9-2
Distribution: unstable
Urgency: low
Maintainer: Mark Howard [EMAIL PROTECTED]
Changed-By: Mark Howard [EMAIL PROTECTED]
Description: 
 galeon - GNOME web browser for advanced users
Changes: 
 galeon (1.3.9-2) unstable; urgency=low
 .
   * Nautilus lib build dependency to = 2.2.4-4.1 (Fixes nautilus
 dependency problems which were causing galeon FTBFS)
Files: 
 7862f0e3d926b809f45884c578a22853 1084 gnome optional galeon_1.3.9-2.dsc
 11b3cda9e1bf87870837e338ed2f9212 46632 gnome optional galeon_1.3.9-2.diff.gz

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

iD8DBQE/e+e4RIB09ZZvujwRAmDbAKDNjCZlABWZs4YoOTvvnYYPuoXT2wCfaA+h
8eOxSWq0zsonXZShB2gRNjU=
=9S+i
-END PGP SIGNATURE-


Accepted:
galeon_1.3.9-2.diff.gz
  to pool/main/g/galeon/galeon_1.3.9-2.diff.gz
galeon_1.3.9-2.dsc
  to pool/main/g/galeon/galeon_1.3.9-2.dsc


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

Accepted rdtool 0.6.14-2 (all source)

2003-10-02 Thread akira yamada

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 18:04:18 +0900
Source: rdtool
Binary: librd-ruby1.8 rdtool-elisp rdtool
Architecture: source all
Version: 0.6.14-2
Distribution: unstable
Urgency: low
Maintainer: akira yamada [EMAIL PROTECTED]
Changed-By: akira yamada [EMAIL PROTECTED]
Description: 
 librd-ruby1.8 - RDTool library for Ruby 1.8
 rdtool - RD document formatter
 rdtool-elisp - Emacs-lisp rd-mode for writing RD document
Closes: 212528 213328
Changes: 
 rdtool (0.6.14-2) unstable; urgency=low
 .
   * librd-ruby1.8 depends on libstrscan-ruby1.8, closes: #213328, #212528.
   * moved /usr/lib/ruby/1.8/rd/* to librd-ruby1.8 from rdtool.
Files: 
 339646ad4c494df383a8318b72ee73ee 634 text optional rdtool_0.6.14-2.dsc
 ec9017570e889276b1b74beb0129052f 5274 text optional rdtool_0.6.14-2.diff.gz
 11efa7650a4d5529254463f120a8d72e 17240 text optional rdtool_0.6.14-2_all.deb
 6fc00cc896f4ac26c710e582f08b8dad 29566 text optional librd-ruby1.8_0.6.14-2_all.deb
 c91d414dbeaa429b8701c73e15f99c28 8704 text optional rdtool-elisp_0.6.14-2_all.deb

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

iD8DBQE/e+wIXzkxpuIT8aARAvMsAJ4hHdhkoWmGQ0C8Eqr5SUoQ/Pt2AwCfVZxQ
79YHyXWqcq7R3W1SLc+TzHY=
=SJmE
-END PGP SIGNATURE-


Accepted:
librd-ruby1.8_0.6.14-2_all.deb
  to pool/main/r/rdtool/librd-ruby1.8_0.6.14-2_all.deb
rdtool-elisp_0.6.14-2_all.deb
  to pool/main/r/rdtool/rdtool-elisp_0.6.14-2_all.deb
rdtool_0.6.14-2.diff.gz
  to pool/main/r/rdtool/rdtool_0.6.14-2.diff.gz
rdtool_0.6.14-2.dsc
  to pool/main/r/rdtool/rdtool_0.6.14-2.dsc
rdtool_0.6.14-2_all.deb
  to pool/main/r/rdtool/rdtool_0.6.14-2_all.deb


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

Accepted cfengine2 2.0.9+2.1.0b3-1 (i386 source all)

2003-10-02 Thread Andrew Stribblehill

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 29 Sep 2003 09:55:18 +0100
Source: cfengine2
Binary: cfengine2-doc cfengine2
Architecture: source i386 all
Version: 2.0.9+2.1.0b3-1
Distribution: unstable
Urgency: high
Maintainer: Andrew Stribblehill [EMAIL PROTECTED]
Changed-By: Andrew Stribblehill [EMAIL PROTECTED]
Description: 
 cfengine2  - Tool for configuring and maintaining network machines
 cfengine2-doc - HTML and Info documentation for cfengine2
Closes: 212891
Changes: 
 cfengine2 (2.0.9+2.1.0b3-1) unstable; urgency=high
 .
   * New upstream version with security fix for cfservd. See
 http://mail.gnu.org/archive/html/bug-cfengine/2003-09/msg00013.html.
 Closes: Bug#212891.
Files: 
 80dcd8cc31b6d039b267503839a89fa5 781 admin optional cfengine2_2.0.9+2.1.0b3-1.dsc
 c33c6ab14f3a3b43d35afdd6c09f6ca5 1276247 admin optional 
cfengine2_2.0.9+2.1.0b3.orig.tar.gz
 9569b0b4a1f3cfd235c9517f6bc748f7 29271 admin optional 
cfengine2_2.0.9+2.1.0b3-1.diff.gz
 d68656deb0168af8f7e205c30006c150 454028 doc extra 
cfengine2-doc_2.0.9+2.1.0b3-1_all.deb
 889a698c2d9541d46f86530bfcfd888d 520210 admin optional 
cfengine2_2.0.9+2.1.0b3-1_i386.deb

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

iD8DBQE/e++6cByyo9pgKCIRAv2xAJ0V22lW4aBgk7QthwUO3jgAVR8POQCfRCL/
mCHChWXyIlokUYLmng/79bc=
=NVl6
-END PGP SIGNATURE-


Accepted:
cfengine2-doc_2.0.9+2.1.0b3-1_all.deb
  to pool/main/c/cfengine2/cfengine2-doc_2.0.9+2.1.0b3-1_all.deb
cfengine2_2.0.9+2.1.0b3-1.diff.gz
  to pool/main/c/cfengine2/cfengine2_2.0.9+2.1.0b3-1.diff.gz
cfengine2_2.0.9+2.1.0b3-1.dsc
  to pool/main/c/cfengine2/cfengine2_2.0.9+2.1.0b3-1.dsc
cfengine2_2.0.9+2.1.0b3-1_i386.deb
  to pool/main/c/cfengine2/cfengine2_2.0.9+2.1.0b3-1_i386.deb
cfengine2_2.0.9+2.1.0b3.orig.tar.gz
  to pool/main/c/cfengine2/cfengine2_2.0.9+2.1.0b3.orig.tar.gz


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

Accepted kernel-patch-2.4.22-powerpc 2.4.22-1 (powerpc all source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Wed, 24 Sep 2003 17:06:38 +0200
Source: kernel-patch-2.4.22-powerpc
Binary: nic-modules-shared-2.4.22-powerpc-udeb kernel-image-2.4.22-powerpc-smp 
ide-modules-2.4.22-powerpc-udeb scsi-modules-2.4.22-powerpc-udeb 
kernel-patch-2.4.22-powerpc socket-modules-2.4.22-powerpc-udeb 
ppp-modules-2.4.22-powerpc-udeb nic-modules-extra-2.4.22-powerpc-udeb 
kernel-image-2.4.22-powerpc kernel-headers-2.4.22 serial-modules-2.4.22-powerpc-udeb 
plip-modules-2.4.22-powerpc-udeb nic-modules-2.4.22-powerpc-udeb 
kernel-image-2.4.22-powerpc-udeb
Architecture: source powerpc all
Version: 2.4.22-1
Distribution: unstable
Urgency: low
Maintainer: Sven Luther [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description: 
 ide-modules-2.4.22-powerpc-udeb - IDE drivers (udeb)
 kernel-headers-2.4.22 - Header files related to a specific Linux kernel.
 kernel-image-2.4.22-powerpc - Linux kernel binary image.
 kernel-image-2.4.22-powerpc-smp - Linux kernel binary image.
 kernel-image-2.4.22-powerpc-udeb - Linux kernel binary image for the Debian installer 
(udeb)
 kernel-patch-2.4.22-powerpc - Diffs to the kernel source for PowerPC
 nic-modules-2.4.22-powerpc-udeb - Common NIC drivers (udeb)
 nic-modules-extra-2.4.22-powerpc-udeb - Rare NIC drivers (udeb)
 nic-modules-shared-2.4.22-powerpc-udeb - Shared NIC drivers (udeb)
 plip-modules-2.4.22-powerpc-udeb - PLIP drivers (udeb)
 ppp-modules-2.4.22-powerpc-udeb - PPP drivers (udeb)
 scsi-modules-2.4.22-powerpc-udeb - SCSI drivers (udeb)
 serial-modules-2.4.22-powerpc-udeb - Serial drivers (udeb)
 socket-modules-2.4.22-powerpc-udeb - Socket drivers (udeb)
Changes: 
 kernel-patch-2.4.22-powerpc (2.4.22-1) unstable; urgency=low
 .
   * New upstream release.
Files: 
 cd99986d2d9dde1c5306f8719f366c64 1061 devel optional 
kernel-patch-2.4.22-powerpc_2.4.22-1.dsc
 bdfa3bd60d9d907eeddfa705d8620a82 61852 devel optional 
kernel-patch-2.4.22-powerpc_2.4.22-1.tar.gz
 64fdb3393629459803c3dcca7f90f9ac 46284 devel optional 
kernel-patch-2.4.22-powerpc_2.4.22-1_all.deb
 793d411a9c9a8274c9b2e046b545eee4 1553068 debian-installer extra 
kernel-image-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
 ec66bab2e1b74876bed85442232b017f 74202 debian-installer extra 
nic-modules-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
 8bbe5d3e50cb2f1b4c353e669d60f9d4 79090 debian-installer extra 
nic-modules-extra-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
 9d4a06a3cdf7d145e9df120062315326 9184 debian-installer extra 
nic-modules-shared-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
 42fb8eb4535c90bec3a464aa0ffcf8f8 16874 debian-installer extra 
serial-modules-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
 4849e00246a0bbf0333722ec6d80fe15 40402 debian-installer extra 
ppp-modules-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
 2cd13dcab8d06a1bacce3d00a9339196 11858 debian-installer extra 
socket-modules-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
 b2b188fd299fddfbb777e21bb5a8f85c 16824 debian-installer extra 
ide-modules-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
 2bdcd685a903377fab07f88bc1640ca9 1285540 debian-installer extra 
scsi-modules-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
 0a404daaf97bb1ebf9606f101e2d907b 26942 debian-installer extra 
plip-modules-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
 11d18b338fd37289f61c510e2c498a90 11930074 base optional 
kernel-image-2.4.22-powerpc_2.4.22-1_powerpc.deb
 a941d6894e8669d2b1cece04ff7c 12137150 base optional 
kernel-image-2.4.22-powerpc-smp_2.4.22-1_powerpc.deb
 3b0087267418af91f79cf24f2752639b 4490356 devel optional 
kernel-headers-2.4.22_2.4.22-1_powerpc.deb

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

iD8DBQE/dTbd2WTeT3CRQaQRAnEmAJ9nQVkPeHHkz/CpYpZJBpz5pXsGVACglN19
lLO3nEmJat4uxoBYzgFPv3k=
=tTHw
-END PGP SIGNATURE-


Accepted:
ide-modules-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
  to 
pool/main/k/kernel-patch-2.4.22-powerpc/ide-modules-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
kernel-headers-2.4.22_2.4.22-1_powerpc.deb
  to pool/main/k/kernel-patch-2.4.22-powerpc/kernel-headers-2.4.22_2.4.22-1_powerpc.deb
kernel-image-2.4.22-powerpc-smp_2.4.22-1_powerpc.deb
  to 
pool/main/k/kernel-patch-2.4.22-powerpc/kernel-image-2.4.22-powerpc-smp_2.4.22-1_powerpc.deb
kernel-image-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
  to 
pool/main/k/kernel-patch-2.4.22-powerpc/kernel-image-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb
kernel-image-2.4.22-powerpc_2.4.22-1_powerpc.deb
  to 
pool/main/k/kernel-patch-2.4.22-powerpc/kernel-image-2.4.22-powerpc_2.4.22-1_powerpc.deb
kernel-patch-2.4.22-powerpc_2.4.22-1.dsc
  to pool/main/k/kernel-patch-2.4.22-powerpc/kernel-patch-2.4.22-powerpc_2.4.22-1.dsc
kernel-patch-2.4.22-powerpc_2.4.22-1.tar.gz
  to 
pool/main/k/kernel-patch-2.4.22-powerpc/kernel-patch-2.4.22-powerpc_2.4.22-1.tar.gz
kernel-patch-2.4.22-powerpc_2.4.22-1_all.deb
  to 
pool/main/k/kernel-patch-2.4.22-powerpc/kernel-patch-2.4.22-powerpc_2.4.22-1_all.deb
nic-modules-2.4.22-powerpc-udeb_2.4.22-1_powerpc.udeb

Accepted tkrat 1:2.1.2-1 (i386 source)

2003-10-02 Thread Mattia Monga

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 30 Sep 2003 08:12:58 +0200
Source: tkrat
Binary: tkrat
Architecture: source i386
Version: 1:2.1.2-1
Distribution: unstable
Urgency: low
Maintainer: Mattia Monga [EMAIL PROTECTED]
Changed-By: Mattia Monga [EMAIL PROTECTED]
Description: 
 tkrat  - Tk based MUA
Changes: 
 tkrat (1:2.1.2-1) unstable; urgency=low
 .
* New upstream version
* control (Standards-Version): 3.6.1
* Revert to upstream modified c-client lib. The Debian one doesn't work
  with tcl/tk 8.4. Modifications needed to be coherent with Debian were
  copied from uw-imap-2002ddebian1 package and isolated in
  01_adapt_upstream_c_client
Files: 
 63334ce6f1031d483d8d148e71e679c7 576 mail extra tkrat_2.1.2-1.dsc
 7ecb7a1cf4a4058a859f44a63ff5c32c 2058554 mail extra tkrat_2.1.2-1.tar.gz
 5dc8949f3d5825dff30c9adb74591d17 1055230 mail extra tkrat_2.1.2-1_i386.deb

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

iD8DBQE/e/vAhGp022U49b8RAsewAKDnZMNnpbR8whoSrxc4MpuHmHYfDwCfYyKB
/wdwSi7Xso2fuOyzB0t2Vc4=
=UtSA
-END PGP SIGNATURE-


Accepted:
tkrat_2.1.2-1.dsc
  to pool/main/t/tkrat/tkrat_2.1.2-1.dsc
tkrat_2.1.2-1.tar.gz
  to pool/main/t/tkrat/tkrat_2.1.2-1.tar.gz
tkrat_2.1.2-1_i386.deb
  to pool/main/t/tkrat/tkrat_2.1.2-1_i386.deb


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

Accepted aqsis 0.8.0-2 (i386 source)

2003-10-02 Thread Will Newton

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 11:36:58 +0100
Source: aqsis
Binary: aqsis-libs-dev aqsis aqsis-libs
Architecture: source i386
Version: 0.8.0-2
Distribution: unstable
Urgency: low
Maintainer: Will Newton [EMAIL PROTECTED]
Changed-By: Will Newton [EMAIL PROTECTED]
Description: 
 aqsis  - A set of applications implementing the RenderMan Interface
 aqsis-libs - A set of applications implementing the RenderMan Interface
 aqsis-libs-dev - A set of applications implementing the RenderMan Interface
Changes: 
 aqsis (0.8.0-2) unstable; urgency=low
 .
   * Modify LD_LIBRARY_PATH correctly during build.
Files: 
 dc9496d7f6ccab551d330d025468f7f5 689 graphics optional aqsis_0.8.0-2.dsc
 1392370c3251321a4774ac2ebd5ec374 2821 graphics optional aqsis_0.8.0-2.diff.gz
 6c26b8f3cf16b0d70bacb3af62ee04e3 141174 graphics optional aqsis_0.8.0-2_i386.deb
 228c0c9fc6deb75779a5e734578499e1 1386760 libs optional aqsis-libs_0.8.0-2_i386.deb
 87104a90c830ad4a3315bda81f55fe8b 109076 libdevel optional 
aqsis-libs-dev_0.8.0-2_i386.deb

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

iD8DBQE/fAMalv9v5CRKz7cRAkoCAJ9g5yRCTML5umykyPkKFAhiWwXwqQCfZooM
/zmpnMr/4vWG6L9NwFGSQe8=
=0XdS
-END PGP SIGNATURE-


Accepted:
aqsis-libs-dev_0.8.0-2_i386.deb
  to pool/main/a/aqsis/aqsis-libs-dev_0.8.0-2_i386.deb
aqsis-libs_0.8.0-2_i386.deb
  to pool/main/a/aqsis/aqsis-libs_0.8.0-2_i386.deb
aqsis_0.8.0-2.diff.gz
  to pool/main/a/aqsis/aqsis_0.8.0-2.diff.gz
aqsis_0.8.0-2.dsc
  to pool/main/a/aqsis/aqsis_0.8.0-2.dsc
aqsis_0.8.0-2_i386.deb
  to pool/main/a/aqsis/aqsis_0.8.0-2_i386.deb


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

Accepted ocaml 3.07-2 (i386 source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 11:41:53 +0200
Source: ocaml
Binary: ocaml-base ocaml ocaml-source ocaml-native-compilers
Architecture: source all i386
Version: 3.07-2
Distribution: unstable
Urgency: low
Maintainer: Sven Luther [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description: 
 ocaml  - ML language implementation with a class-based object system
 ocaml-base - Runtime system for ocaml bytecode executables
 ocaml-native-compilers - Native code compilers of the ocaml suite (the .opt ones)
 ocaml-source - Sources for Objectif Caml
Closes: 205391
Changes: 
 ocaml (3.07-2) unstable; urgency=low
 .
   * I mistakenly uploaded to experimental, and thus am forced to upload a -2.
 .
 ocaml (3.07-1) experimental; urgency=low
 .
   * New upstream release.
 - Most debian patches where included upstream.
 - Standard library now use .3o suffixes. (Closes: #205391)
   * Dpatchification.
   * Applied the camlp4 optional arguments fix.
   * Fixed emacsen-install so that caml-xemacs and caml-emacs get installed
 only for the corresponding emacs flavors. Thanks go to Jerome Marant.
   * Moved ocaml-source into a tarball.
Files: 
 8620ea4f56b4343ee43d8a99b7449c08 668 devel optional ocaml_3.07-2.dsc
 164508c3569d7bd790aa80dd161b5f45 46288 devel optional ocaml_3.07-2.diff.gz
 e1de965cd93b704d43d24394119b4bda 7779418 devel optional ocaml_3.07-2_i386.deb
 266a40b7517460ef6cac3a9fa42031fc 2434118 devel optional 
ocaml-native-compilers_3.07-2_i386.deb
 ba53853ca1b170f14f6c17fea0ae2230 156212 devel optional ocaml-base_3.07-2_i386.deb
 81d6016b962fdcac34ff6af1055f01a0 1931340 devel optional ocaml-source_3.07-2_all.deb

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

iD8DBQE/fADV2WTeT3CRQaQRAqZ8AJ0U/Ob/Ro1VTM1qi3RqsEAKtiSVOACfbrU5
S+PVvld0LFV6Ios/e2gMC6E=
=Uiaj
-END PGP SIGNATURE-


Accepted:
ocaml-base_3.07-2_i386.deb
  to pool/main/o/ocaml/ocaml-base_3.07-2_i386.deb
ocaml-native-compilers_3.07-2_i386.deb
  to pool/main/o/ocaml/ocaml-native-compilers_3.07-2_i386.deb
ocaml-source_3.07-2_all.deb
  to pool/main/o/ocaml/ocaml-source_3.07-2_all.deb
ocaml_3.07-2.diff.gz
  to pool/main/o/ocaml/ocaml_3.07-2.diff.gz
ocaml_3.07-2.dsc
  to pool/main/o/ocaml/ocaml_3.07-2.dsc
ocaml_3.07-2_i386.deb
  to pool/main/o/ocaml/ocaml_3.07-2_i386.deb


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

Accepted nvtv 0.4.5-1 (i386 source)

2003-10-02 Thread Eduard Bloch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 12:40:58 +0200
Source: nvtv
Binary: nvtv
Architecture: source i386
Version: 0.4.5-1
Distribution: unstable
Urgency: low
Maintainer: Eduard Bloch [EMAIL PROTECTED]
Changed-By: Eduard Bloch [EMAIL PROTECTED]
Description: 
 nvtv   - Tool to control TV chips on NVidia cards under Linux
Closes: 192455
Changes: 
 nvtv (0.4.5-1) unstable; urgency=low
 .
   * New upstream release
 + uses X_FLAGS instead of $x_includes (closes: #192455)
Files: 
 6e7c4c00f18a59434a02313604e93397 617 admin optional nvtv_0.4.5-1.dsc
 2807dcd92cf3847614e72076527b2b25 383497 admin optional nvtv_0.4.5.orig.tar.gz
 bf9a720d2e6643d4577855175591b7d0 3053 admin optional nvtv_0.4.5-1.diff.gz
 0aaa5df6f43f80aa844b8e3cf410ddf8 258518 admin optional nvtv_0.4.5-1_i386.deb

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

iD8DBQE/fA384QZIHu3wCMURArV3AJ4qrmdSsjJxY50SIA2/CmjIbN79vQCeOqb3
0xcTsk12TfQvcMGDjyxPyNQ=
=DuEb
-END PGP SIGNATURE-


Accepted:
nvtv_0.4.5-1.diff.gz
  to pool/main/n/nvtv/nvtv_0.4.5-1.diff.gz
nvtv_0.4.5-1.dsc
  to pool/main/n/nvtv/nvtv_0.4.5-1.dsc
nvtv_0.4.5-1_i386.deb
  to pool/main/n/nvtv/nvtv_0.4.5-1_i386.deb
nvtv_0.4.5.orig.tar.gz
  to pool/main/n/nvtv/nvtv_0.4.5.orig.tar.gz


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

Accepted atokx 1.0-14 (i386 source)

2003-10-02 Thread Taku YASUI

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 21:22:42 +0900
Source: atokx
Binary: atokx
Architecture: source i386
Version: 1.0-14
Distribution: unstable
Urgency: low
Maintainer: Taku YASUI [EMAIL PROTECTED]
Changed-By: Taku YASUI [EMAIL PROTECTED]
Description: 
 atokx  - Kana-Kanji translation system ATOKX for Linux (Installer)
Changes: 
 atokx (1.0-14) unstable; urgency=low
 .
   * Fix: atokx daemon cannot start when the symlinks are broken
Files: 
 7497c8456c2ba5f37b5055d93c36b89e 500 contrib/utils optional atokx_1.0-14.dsc
 f8926c77abbf2190be9e3e31acfbf0d4 10267 contrib/utils optional atokx_1.0-14.tar.gz
 38f57b496715ce3de992f8ad1387d64c 9594 contrib/utils optional atokx_1.0-14_i386.deb

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

iD8DBQE/fBjUFwU5DuZsm7ARAuECAKDcBhoNQI5jTV6Zvji2MAvQf2XP4gCfTZHq
p0e4wvpgAEmym9w1d2yO8rM=
=ybqj
-END PGP SIGNATURE-


Accepted:
atokx_1.0-14.dsc
  to pool/contrib/a/atokx/atokx_1.0-14.dsc
atokx_1.0-14.tar.gz
  to pool/contrib/a/atokx/atokx_1.0-14.tar.gz
atokx_1.0-14_i386.deb
  to pool/contrib/a/atokx/atokx_1.0-14_i386.deb


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

Accepted beep 1.2.2-12 (i386 source)

2003-10-02 Thread Gerfried Fuchs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 02 Oct 2003 11:35:43 +
Source: beep
Binary: beep
Architecture: source i386
Version: 1.2.2-12
Distribution: unstable
Urgency: low
Maintainer: Gerfried Fuchs [EMAIL PROTECTED]
Changed-By: Gerfried Fuchs [EMAIL PROTECTED]
Description: 
 beep   - Advanced pc-speaker beeper
Closes: 209118
Changes: 
 beep (1.2.2-12) unstable; urgency=low
 .
   * Added Dutch debconf file from Tim Vandermeersch (closes: #209118)
   * Updated Russian template, thanks to Ilgiz Kalmetev.
   * Updated to policy version 3.6.1, no changes needed.
   * Switched to utf8 for the changelog.Debian.
Files: 
 916a86b728745289384314da29827c68 540 sound optional beep_1.2.2-12.dsc
 1aee0357fa19883c3f983d6ff07c7d49 7583 sound optional beep_1.2.2-12.diff.gz
 f7d84407a98a0f04a101648e0a093bd2 17894 sound optional beep_1.2.2-12_i386.deb

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

iD8DBQE/fBs4ELuA/Ba9d8YRAoxgAJ9HAmdeoWmc6JLrJs1Zp2CDSoJD9gCdFsLS
JENiKUbSzIBDYoN4lwyINAI=
=RP1B
-END PGP SIGNATURE-


Accepted:
beep_1.2.2-12.diff.gz
  to pool/main/b/beep/beep_1.2.2-12.diff.gz
beep_1.2.2-12.dsc
  to pool/main/b/beep/beep_1.2.2-12.dsc
beep_1.2.2-12_i386.deb
  to pool/main/b/beep/beep_1.2.2-12_i386.deb


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

Accepted openvrml 0.13.0-6 (source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 14:44:17 +0200
Source: openvrml
Binary: libopenvrml3 openvrml-lookat libopenvrml3-dev
Architecture: source
Version: 0.13.0-6
Distribution: unstable
Urgency: low
Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Description: 
 libopenvrml3 - runtime shared library for VRML
 libopenvrml3-dev - developer libraries for openvrml
 openvrml-lookat - VRML viewer for X11
Closes: 209676
Changes: 
 openvrml (0.13.0-6) unstable; urgency=low
 .
   * debian/control:
 + Rephrased short descriptions.
 + Wrote more meaningful long descriptions (Closes: #209676).
Files: 
 daf27387e898a49d176aa2ae3390bd98 771 libs optional openvrml_0.13.0-6.dsc
 5a5c919435133190508b1da390224375 286005 libs optional openvrml_0.13.0-6.diff.gz

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

iD8DBQE/fB9GfPP1rylJn2ERAoEQAJ9u2jyHyuG6u2m3xcH16NviKUgPbQCeNJgx
6AL6NQ0wFLHzmS7Z8/M5u1A=
=Rw2l
-END PGP SIGNATURE-


Accepted:
openvrml_0.13.0-6.diff.gz
  to pool/main/o/openvrml/openvrml_0.13.0-6.diff.gz
openvrml_0.13.0-6.dsc
  to pool/main/o/openvrml/openvrml_0.13.0-6.dsc


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

Accepted svn-devscripts 0.3 (all source)

2003-10-02 Thread Eduard Bloch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 10:04:19 +0200
Source: svn-devscripts
Binary: svn-devscripts
Architecture: source all
Version: 0.3
Distribution: unstable
Urgency: low
Maintainer: Eduard Bloch [EMAIL PROTECTED]
Changed-By: Eduard Bloch [EMAIL PROTECTED]
Description: 
 svn-devscripts - helpers to maintain Debian packages with Subversion
Changes: 
 svn-devscripts (0.3) unstable; urgency=low
 .
   * rework of the checkout code in svn-inject, and verbosity control
   * clean call fixed, merge-with-upstream mode enabling check fixed to not
 produce false positives
Files: 
 81b6e124ee2d8e1d15561cced8fdab60 511 devel extra svn-devscripts_0.3.dsc
 8562570a3e29f953d8160fb15d85c388 18145 devel extra svn-devscripts_0.3.tar.gz
 e82850fc10270fb6a64f6749e3615dcf 20460 devel extra svn-devscripts_0.3_all.deb

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

iD8DBQE/fB794QZIHu3wCMURAn2HAJ9A7mbh6A2jTuSJ9fcozKuMwONRXgCdFg9E
Hjg+o8FzUyu35epierdRzsc=
=jDE7
-END PGP SIGNATURE-


Accepted:
svn-devscripts_0.3.dsc
  to pool/main/s/svn-devscripts/svn-devscripts_0.3.dsc
svn-devscripts_0.3.tar.gz
  to pool/main/s/svn-devscripts/svn-devscripts_0.3.tar.gz
svn-devscripts_0.3_all.deb
  to pool/main/s/svn-devscripts/svn-devscripts_0.3_all.deb


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

Accepted allegro4 2:4.0.3-10 (source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 14:53:28 +0200
Source: allegro4
Binary: liballegro-dev liballegro4a-plugin-svgalib liballegro4a-dbg allegro-demo 
liballegro4a-plugin-esd allegro-examples liballegro4a liballegro-doc 
liballegro4a-plugin-arts
Architecture: source
Version: 2:4.0.3-10
Distribution: unstable
Urgency: low
Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Description: 
 allegro-demo - cool game, demonstrating power of the Allegro library
 allegro-examples - example programs and demo tools for the Allegro library
 liballegro-dev - development files for the Allegro library
 liballegro-doc - documentation for the Allegro library
 liballegro4a - portable library for cross-platform game and multimedia developme
 liballegro4a-dbg - debugging libraries for Allegro
 liballegro4a-plugin-arts - aRts audio plugin for the Allegro library
 liballegro4a-plugin-esd - esd audio plugin for the Allegro library
 liballegro4a-plugin-svgalib - SVGAlib video plugin for the Allegro library
Closes: 209740
Changes: 
 allegro4 (2:4.0.3-10) unstable; urgency=low
 .
   * debian/control:
 + Set the liballegro-dbg package's priority to extra.
 + Set policy to 3.6.1.0.
 + Wrote more meaningful long descriptions (Closes: #209740).
Files: 
 c4d12956f16555a54093d785ef1d08b4 847 devel optional allegro4_4.0.3-10.dsc
 99e372cbc5df4509fc03e3a2ce951464 27350 devel optional allegro4_4.0.3-10.diff.gz

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

iD8DBQE/fCHcfPP1rylJn2ERAvoIAJ9qsSYX9m90L/DcEa1xBtel+MqvDgCgqFaj
IwJWuoFcxU5qP1s54xXAsB8=
=5j0U
-END PGP SIGNATURE-


Accepted:
allegro4_4.0.3-10.diff.gz
  to pool/main/a/allegro4/allegro4_4.0.3-10.diff.gz
allegro4_4.0.3-10.dsc
  to pool/main/a/allegro4/allegro4_4.0.3-10.dsc


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

Accepted bsd-ftpd 0.3.3-16 (i386 source)

2003-10-02 Thread Michael Vogt

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 13:28:58 +0200
Source: bsd-ftpd
Binary: bsd-ftpd
Architecture: source i386
Version: 0.3.3-16
Distribution: unstable
Urgency: low
Maintainer: Michael Vogt [EMAIL PROTECTED]
Changed-By: Michael Vogt [EMAIL PROTECTED]
Description: 
 bsd-ftpd   - Port of the OpenBSD FTP server
Closes: 20632 174886 187780
Changes: 
 bsd-ftpd (0.3.3-16) unstable; urgency=low
 .
   * added frensh po-debconf translation (closes: #20632)
   * added brazilian Portuguese translation (closes: #187780)
   * spanish debconf translation is now handled via po-debconf and is
 up-to-date (closes: #174886)
Files: 
 32f9cdf8319bf2a74f57d16fb0041bf9 592 net optional bsd-ftpd_0.3.3-16.dsc
 c4661e5809472efebce11455115f0aa1 15531 net optional bsd-ftpd_0.3.3-16.diff.gz
 52c57589c6ac7799876c918b8f0abfbf 51278 net optional bsd-ftpd_0.3.3-16_i386.deb

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

iD8DBQE/fCODliSD4VZixzQRAhkzAKCWbidxEq+56MRwWmb83ht+LvghMgCfcozx
3nsBspCIq0quN7qo8T08UTI=
=G61y
-END PGP SIGNATURE-


Accepted:
bsd-ftpd_0.3.3-16.diff.gz
  to pool/main/b/bsd-ftpd/bsd-ftpd_0.3.3-16.diff.gz
bsd-ftpd_0.3.3-16.dsc
  to pool/main/b/bsd-ftpd/bsd-ftpd_0.3.3-16.dsc
bsd-ftpd_0.3.3-16_i386.deb
  to pool/main/b/bsd-ftpd/bsd-ftpd_0.3.3-16_i386.deb


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

Accepted quickml 0.5+20030909-2 (all source)

2003-10-02 Thread Fumitoshi UKAI

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 22:51:58 +0900
Source: quickml
Binary: quickml
Architecture: source all
Version: 0.5+20030909-2
Distribution: unstable
Urgency: low
Maintainer: Fumitoshi UKAI [EMAIL PROTECTED]
Changed-By: Fumitoshi UKAI [EMAIL PROTECTED]
Description: 
 quickml- Very-easy-to-use mailing list system
Closes: 213740
Changes: 
 quickml (0.5+20030909-2) unstable; urgency=low
 .
   * use $(RUBY) instead of ruby.
 closes: Bug#213740
Files: 
 75eab3f3c28ca1562907f2df5bc361d1 537 mail optional quickml_0.5+20030909-2.dsc
 4668d2fa81be274fcef233b9a0974b42 38159 mail optional quickml_0.5+20030909-2.tar.gz
 3de54ed9f788e041b899ff7da48c7512 29116 mail optional quickml_0.5+20030909-2_all.deb

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

iD8DBQE/fC3I9D5yZjzIjAkRAkaaAJ9oCyQmnL/nF5s3j1bCK/PwI7XtqwCdFJ12
jrV07JsnGyv8MTEFNB6aG3Q=
=yibd
-END PGP SIGNATURE-


Accepted:
quickml_0.5+20030909-2.dsc
  to pool/main/q/quickml/quickml_0.5+20030909-2.dsc
quickml_0.5+20030909-2.tar.gz
  to pool/main/q/quickml/quickml_0.5+20030909-2.tar.gz
quickml_0.5+20030909-2_all.deb
  to pool/main/q/quickml/quickml_0.5+20030909-2_all.deb


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

Accepted rafkill 1.1.0-4 (source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 15:17:21 +0200
Source: rafkill
Binary: rafkill-data rafkill
Architecture: source
Version: 1.1.0-4
Distribution: unstable
Urgency: low
Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Description: 
 rafkill- vertical shoot'em-up similar to Raptor: Call of the Shadows
 rafkill-data - graphics and audio data for rafkill
Closes: 198604 209748
Changes: 
 rafkill (1.1.0-4) unstable; urgency=low
 .
   * src/rfield.cpp:
 + Duplicate the text handle with strdup() and free it with free(), not
   delete[]. Fixes a crash when selling the main weapon (Closes: #198604).
   * debian/control:
 + Set policy to 3.6.1.0.
 + Wrote more meaningful long descriptions (Closes: #209748).
Files: 
 e1c5952b5543733cdcfcc83402ceeedc 640 games optional rafkill_1.1.0-4.dsc
 40b21408ca8337a729fed94d8f694d2b 421523 games optional rafkill_1.1.0-4.diff.gz

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

iD8DBQE/fCa+fPP1rylJn2ERAorlAJ4s7CUaam2RFCGp5HtWR5z9nATstACfYJ2r
wuv1VqQUztPJWebGLDxCOLo=
=Y/N+
-END PGP SIGNATURE-


Accepted:
rafkill_1.1.0-4.diff.gz
  to pool/main/r/rafkill/rafkill_1.1.0-4.diff.gz
rafkill_1.1.0-4.dsc
  to pool/main/r/rafkill/rafkill_1.1.0-4.dsc


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

Accepted powermanga 0.78-3 (source)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 15:27:08 +0200
Source: powermanga
Binary: powermanga powermanga-data
Architecture: source
Version: 0.78-3
Distribution: unstable
Urgency: low
Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED]
Description: 
 powermanga - vertical shoot 'em up for X11 with colourful 3D graphics
 powermanga-data - graphics and audio data for powermanga
Closes: 209859
Changes: 
 powermanga (0.78-3) unstable; urgency=low
 .
   * debian/control:
  + Set policy to 3.6.1.0.
  + Wrote more meaningful long descriptions (Closes: #209859).
Files: 
 f5bced6a90773b1e29308e1124e0d38b 666 games optional powermanga_0.78-3.dsc
 d64f76a3162ab5cba0423c6c1ab4ea7c 12917 games optional powermanga_0.78-3.diff.gz

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

iD8DBQE/fCgifPP1rylJn2ERAkCuAJ41JS/zOsxwyL28lSbxcrKEpPDXdQCdERkk
pKX0JdV9kvztQUGikoM5D7U=
=PpwW
-END PGP SIGNATURE-


Accepted:
powermanga_0.78-3.diff.gz
  to pool/main/p/powermanga/powermanga_0.78-3.diff.gz
powermanga_0.78-3.dsc
  to pool/main/p/powermanga/powermanga_0.78-3.dsc


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

Accepted xmms-mad 0.5.5-1 (i386 source)

2003-10-02 Thread Sam Clegg

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 13:24:54 +0100
Source: xmms-mad
Binary: xmms-mad
Architecture: source i386
Version: 0.5.5-1
Distribution: unstable
Urgency: low
Maintainer: Sam Clegg [EMAIL PROTECTED]
Changed-By: Sam Clegg [EMAIL PROTECTED]
Description: 
 xmms-mad   - mp3 input plugin for xmms based on libmad
Closes: 211083
Changes: 
 xmms-mad (0.5.5-1) unstable; urgency=low
 .
   * New upstream release
   * Closes: #211083: xmms skips all .mp3s when only enabling this input
 plugin
   * debian/control: maintainer typo: sam-samo
   * Bumped standards version from 3.5.7 to 2.6.1
Files: 
 b85633687ef8af363d9f78be675789d6 624 sound optional xmms-mad_0.5.5-1.dsc
 62bfda386bdcc4466de86b885427005c 307441 sound optional xmms-mad_0.5.5.orig.tar.gz
 23f46b075c40f032eaf598a27a0e0881 3295 sound optional xmms-mad_0.5.5-1.diff.gz
 56887aa962e83aab14ad2de7e738ba7c 23630 sound optional xmms-mad_0.5.5-1_i386.deb

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

iD8DBQE/fCbkLOvxONke42kRAgsKAJ4khQvgE66ZMpdMhHQkNAB5pW6NjgCgrilK
XyCiMm4nndWwgNr7J2D3jUU=
=Lc8y
-END PGP SIGNATURE-


Accepted:
xmms-mad_0.5.5-1.diff.gz
  to pool/main/x/xmms-mad/xmms-mad_0.5.5-1.diff.gz
xmms-mad_0.5.5-1.dsc
  to pool/main/x/xmms-mad/xmms-mad_0.5.5-1.dsc
xmms-mad_0.5.5-1_i386.deb
  to pool/main/x/xmms-mad/xmms-mad_0.5.5-1_i386.deb
xmms-mad_0.5.5.orig.tar.gz
  to pool/main/x/xmms-mad/xmms-mad_0.5.5.orig.tar.gz


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

Accepted python-stats 0.6-3 (all source)

2003-10-02 Thread Matthias Klose

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu,  2 Oct 2003 15:26:34 +0200
Source: python-stats
Binary: python-stats
Architecture: source all
Version: 0.6-3
Distribution: unstable
Urgency: medium
Maintainer: Matthias Klose [EMAIL PROTECTED]
Changed-By: Matthias Klose [EMAIL PROTECTED]
Description: 
 python-stats - A collection of statistical functions for Python
Closes: 212110
Changes: 
 python-stats (0.6-3) unstable; urgency=medium
 .
   * Remove debian/dirs (really closes: #212110).
Files: 
 7a0cca1e2cd3b2556630ac5a226edb33 581 python optional python-stats_0.6-3.dsc
 45d551d05afb9b715f95a37d3cb5875a 55914 python optional python-stats_0.6-3.diff.gz
 e93d81bc59921971f18695f78e0bb9ae 64550 python optional python-stats_0.6-3_all.deb

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

iD8DBQE/fCndStlRaw+TLJwRAhcTAJ4zBpyauJpNjcGCMBSvUJpmBmRouACfVrNp
/EHE5xR5YFKWBllu3axfvlM=
=NRqf
-END PGP SIGNATURE-


Accepted:
python-stats_0.6-3.diff.gz
  to pool/main/p/python-stats/python-stats_0.6-3.diff.gz
python-stats_0.6-3.dsc
  to pool/main/p/python-stats/python-stats_0.6-3.dsc
python-stats_0.6-3_all.deb
  to pool/main/p/python-stats/python-stats_0.6-3_all.deb


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

Accepted kq 0.98+cvs.20030615-2 (source)