Re: Bug#417261: dch: please use dates in UTC

[Stefano Zacchiroli]

On Wed, Apr 04, 2007 at 05:58:28PM +0200, Christoph Berg wrote:
> What about supporting a variable DEBCHANGE_TZ in ~/.devscripts that
> lets the user set UTC, but defaults to $TZ?

That would be a one-size-fits-all solution I would like.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Bug#417261: dch: please use dates in UTC

[Loïc Minier]

On Wed, Apr 04, 2007, Christoph Berg wrote:
> What about supporting a variable DEBCHANGE_TZ in ~/.devscripts that
> lets the user set UTC, but defaults to $TZ?

 Uh, isn't alias dch='TZ=UTC dch' good enough?

-- 
Loïc Minier


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

MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

Bug 410474 involves mysql not working on older 486s and some cyrix cpus
which do not have the cpuid instruction.  Any program that tries to use
libmysql (proftpd, php, etc) terminates with illegal instruction.

Upstream tried to fix it, but apparently failed to do so correctly,
although I suspect it does work on BSD if nothing else.

Since I run a 486, and deviced it was time to upgrade to Etch, to see if
there were any issues to report about it before the release happens, I
was rather surprised when proftpd suddenly didn't work.  Commenting out
the mysql module in proftpd's config made it work.  Then I noticed php
didn't work either, if it had mysql enabled, and I tracked down this bug
number.

I have now found a solution to the problem (which makes it solved not
just on BSD where setjmp saves signal context by default, which linux
does not), and added it to the bug.  Of course I don't know if the mysql
maintainer is actually around at the moment to notice and do something
with it.

So does it seem fair to raise the severity to flag mysql as release
critical for etch since it does affect any program that links in
libmysql running on any x86 without cpuid support?  I would hate to see
other people upgrade to Etch on older systems that were working find
just to end up with a bunch of programs no longer working.

--
Len Sorensen


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

Re: Poll: Anybody using debpool?

[Andreas Fester]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Magnus Holmgren wrote:
[...]
>> The package is at
>> http://littletux.homelinux.org/debian/pool/main/d/debpool/
> 
> Some comments:
> 
> * You've indented the main loop in bin/debpool. While I think that's how it 
> should be, I also think it's best to undo it until we have merged all 
> contributions.

Sure. I did this to make the main loop more readable, but for merging
it might be better not to indent it at first. I think that
the main loop is too large anyway and should be refactored to only call
a few other functions.
BTW: I started a wiki page describing debpool at http://wiki.debian.org/debpool
some time ago.

> * SGI::FAM is not a module available in Debian, even in experimental. While 
[...]

http://littletux.homelinux.org/debian/pool/main/libf/libfam-perl/

Simply wanted to wait for the etch release before injecting it into
the perl packages svn repository ;)

I am still running a 2.4 kernel on my server, so it would be good to
have an alternative which does not require a 2.6 kernel.

> * Did you get the init script to work? 
> start-stop-daemon --stop --exec /usr/bin/debpool shouldn't work, 
> since /proc/(pid)/exe points to /usr/bin/perl.

You are right. It was a fast hack mainly to make sure that
debpool *starts* after reboot :)

Did you already think about the further proceeding? Shall we register
a debpool2, debpool-ng or whatsoever project on alioth?

Best Regards,

Andreas

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

iD8DBQFGFWRuZ3bQVzeW+rsRAi1vAKDYmYKtX31O5uOrHdQF9rmWxC3wTwCfVazo
qInBSdHu0u76wjJ+TDmdstA=
=xEnN
-END PGP SIGNATURE-


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

Re: primary mirrors, debootstrap and d-i

[Goswin von Brederlow]

Neil Williams <[EMAIL PROTECTED]> writes:

> On Wed, 04 Apr 2007 10:47:00 +0200
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> Parse sources.list. Many people have multiple suites in there and you
>> will want to add multiple entries then.
>
> apt-cache policy already covers that output and it is easier to parse -
> the code offered by Ben Hutchings adds to my own code by supporting the
> priority figure specified in apt-cache policy, I was already parsing
> the rest. Thanks Ben.

But it lacks information:

% apt-cache policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 http://storage sid/non-free Packages
 release o=Debian,a=unstable,l=Debian,c=non-free
 origin ftp.de.debian.org
 500 http://storage sid/contrib Packages
 release o=Debian,a=unstable,l=Debian,c=contrib
 origin ftp.de.debian.org
 500 http://storage sid/main Packages
 release o=Debian,a=unstable,l=Debian,c=main
 origin ftp.de.debian.org

Now is that
http://storage/debian/sid/main/binary-amd64/Packages
or
http://storage/mirror/debian/sid/main/binary-amd64/Packages
?

You just don't have all the info.


>> You also want to pick a mirror
>> near to the mirror already used.
>
> That won't work - the only reason to add a primary mirror is when the
> system is not using ANY primary mirrors, just something like
> ftp.debian.org as set by debootstrap.

Ah, then I misunderstood what you add and when.

> Am I right in thinking that normal d-i installations ensure that at
> least one primary mirror is selected (or at least strongly advise that
> one primary should exist)?

Nothing wrong with picking ftp.debian.org from the mirror list if one
is in us. D-I takes the full list, filters out mirrors that carry the
requested arch and then tries to pick one from the country the locales
are set to. Otherwise the user gets asked to pick one afaik.

So nothing says the mirror you end up with on i386 will have arm
packages.

> I will look at 'ucf' to manage the file in /etc/apt/sources.list.d/
> - as you suggested. However, if no primary mirror needs to be added
> to /etc/apt/sources.list.d/emdebian.sources.list, I'm not sure ucf is
> necessary - ucf isn't relevant in a debootstrap chroot.

Ucf is neccessary (not strictly speaking but it is a very good idea)
whenever you generate a conffile instead of shipping a premade file
in the package. If you have the option of having a primary mirror
or an empty file then you can't ship the file. So ucf becomes your
friend.

> Options, options . . .

MfG
Goswin


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

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Florian Weimer]

* Lennart Sorensen:

> So does it seem fair to raise the severity to flag mysql as release
> critical for etch since it does affect any program that links in
> libmysql running on any x86 without cpuid support?

Document it in the release notes, please.  It's not worth risking
stability for the majority of users for this kind of bug.

Anyway, is there any particular reason why upstream (or you) don't use
the Intel-recommended way for detection of CPUID support?  A library
twiddling with SIGILL isn't a terribly good idea.


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

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Thu, Apr 05, 2007 at 11:46:16PM +0200, Florian Weimer wrote:
> Document it in the release notes, please.  It's not worth risking
> stability for the majority of users for this kind of bug.
> 
> Anyway, is there any particular reason why upstream (or you) don't use
> the Intel-recommended way for detection of CPUID support?  A library
> twiddling with SIGILL isn't a terribly good idea.

I have no idea.  I just made the smallest change possible to make mysql
not break 486 machines.  The other option is to go back to what was done
for sarge as far as I can tell, which is use the C implementation rather
than the assembly one and loose the performance gains on newer CPUs.

And documenting in the release notes that 486s will break on upgrade
doesn't seem like a particularly good solution without a fixed package
being made.  Well if nothing else it can go into 4.0r1 I guess, or a
proposed update in the mean time.

Now if there is a recomended way to detect cpuid support, then it would
certainly make sense for the upstream to use that instead.  I find the
current method very icky. :)  setjmp, and a SIGILL handler just seems
wrong.  Where does one find the recomended method?

--
Len Sorensen


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

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Fri, Apr 06, 2007 at 12:12:58AM +0200, Sam Hocevar wrote:
>Here's a patch that uses the recommended method.

I will test that out on my 486 and see if that works.  It is certainly
much nicer, so assuming it works I vote for this one instead.

--
Len Sorensen


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

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Sam Hocevar]

tag 410474 +patch
thanks

On Thu, Apr 05, 2007, Florian Weimer wrote:

> Document it in the release notes, please.  It's not worth risking
> stability for the majority of users for this kind of bug.
> 
> Anyway, is there any particular reason why upstream (or you) don't use
> the Intel-recommended way for detection of CPUID support?  A library
> twiddling with SIGILL isn't a terribly good idea.

   Here's a patch that uses the recommended method.

Cheers,
-- 
Sam.
--- ./extra/yassl/taocrypt/src/misc.cpp.orig	2007-04-06 00:02:10 +0200
+++ ./extra/yassl/taocrypt/src/misc.cpp	2007-04-06 00:04:49 +0200
@@ -192,27 +192,29 @@ bool HaveCpuId()
 }
 return true;
 #else
-typedef void (*SigHandler)(int);
+word32 eax, ebx;
 
-SigHandler oldHandler = signal(SIGILL, SigIllHandler);
-if (oldHandler == SIG_ERR)
-return false;
+__asm__ __volatile
+(
+"pushf\n\t"
+"pushf\n\t"
+"pop %0\n\t"
+"movl %0,%1\n\t"
+"xorl $0x20,%0\n\t"
+"push %0\n\t"
+"popf\n\t"
+"pushf\n\t"
+"pop %0\n\t"
+"popf"
+: "=r" (eax), "=r" (ebx)
+:
+: "cc"
+);
 
-bool result = true;
-if (setjmp(s_env))
-result = false;
-else 
-__asm__ __volatile
-(
-// save ebx in case -fPIC is being used
-"push %%ebx; mov $0, %%eax; cpuid; pop %%ebx"
-: 
-:
-: "%eax", "%ecx", "%edx" 
-);
+if (eax == ebx)
+return false;
 
-signal(SIGILL, oldHandler);
-return result;
+return true;
 #endif
 }
 

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Steve Langasek]

On Thu, Apr 05, 2007 at 06:24:04PM -0400, Lennart Sorensen wrote:
> On Thu, Apr 05, 2007 at 11:46:16PM +0200, Florian Weimer wrote:
> > Document it in the release notes, please.  It's not worth risking
> > stability for the majority of users for this kind of bug.

> > Anyway, is there any particular reason why upstream (or you) don't use
> > the Intel-recommended way for detection of CPUID support?  A library
> > twiddling with SIGILL isn't a terribly good idea.

> I have no idea.  I just made the smallest change possible to make mysql
> not break 486 machines.  The other option is to go back to what was done
> for sarge as far as I can tell, which is use the C implementation rather
> than the assembly one and loose the performance gains on newer CPUs.

> And documenting in the release notes that 486s will break on upgrade
> doesn't seem like a particularly good solution without a fixed package
> being made.  Well if nothing else it can go into 4.0r1 I guess, or a
> proposed update in the mean time.

Documenting it in the release notes isn't particularly *relevant* if a fixed
package is made, AFAICS.  The content for the r0 release notes is frozen
now anyway, to let translators catch up, so any mention of this in the
release notes would be included on CDs the same time as the fixed package,
more or less defeating the purpose.  We should probably consider an errata
document for the website, to document r0-specific issues that didn't make it
into the release notes, so that we don't have to choose between dropping
translations for not mentioning such errata and publishing
supposedly-complete translations that don't mention all the errata due to
time constraints.

Anyway, if this bug had been marked as RC at any point in the past months,
it certainly would have been fixed before now.  It's frustrating to see
people escalating bug severities at the very last minute, when the bug has
been known for a while and it's now too late to include a fix in r0 without
causing the release timeline to slip.  (This is not the only bug where this
has been the case; c.f. bug #399761.)  I do remember a bug thread months ago
about cpuid detection in mysql, but the fact that it wasn't listed as an RC
bug anymore means that it quickly fell off of *my* radar.

In practical terms, it seems to me that part of the fix here should really
be to declare that we don't officially support 486 CPUs anymore, since no
one who is using one was involved enough in the etch release to have
documented this bug as RC until three days before release. :P

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


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

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Thu, Apr 05, 2007 at 03:42:28PM -0700, Steve Langasek wrote:
> Documenting it in the release notes isn't particularly *relevant* if a fixed
> package is made, AFAICS.  The content for the r0 release notes is frozen
> now anyway, to let translators catch up, so any mention of this in the
> release notes would be included on CDs the same time as the fixed package,
> more or less defeating the purpose.  We should probably consider an errata
> document for the website, to document r0-specific issues that didn't make it
> into the release notes, so that we don't have to choose between dropping
> translations for not mentioning such errata and publishing
> supposedly-complete translations that don't mention all the errata due to
> time constraints.
> 
> Anyway, if this bug had been marked as RC at any point in the past months,
> it certainly would have been fixed before now.  It's frustrating to see
> people escalating bug severities at the very last minute, when the bug has
> been known for a while and it's now too late to include a fix in r0 without
> causing the release timeline to slip.  (This is not the only bug where this
> has been the case; c.f. bug #399761.)  I do remember a bug thread months ago
> about cpuid detection in mysql, but the fact that it wasn't listed as an RC
> bug anymore means that it quickly fell off of *my* radar.

Well if I had known about it I would have suggested it should be RC.  I
should try to become a DD one of these days... :)

> In practical terms, it seems to me that part of the fix here should really
> be to declare that we don't officially support 486 CPUs anymore, since no
> one who is using one was involved enough in the etch release to have
> documented this bug as RC until three days before release. :P

My 486 actually does a useful job, and hence usually runs pure stable.
I figured I would upgrade it to see if anything broken, and boy did it
ever break.  It is a good old reliable machine and the only 486 I have.
I guess loosing proftpd and php isn't the worst things that can happen,
although I do like my ftp server to work, as well as my web server.  At
least I know have a fixed version installed so my machine works.

Maybe I am the only person left with a 486 doing useful work, but it has
run problem free for 15 years now and shows no signs of giving any.
Hopefully I will replace the 486 with a ppro in the next few months, in
which case the 486 will become available for me to just do tests on and
other experiments.

Is there any good reason 486s should not be supproted anymore?  I know
why 386s are not supported anymore.

--
Len Sorensen


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

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Thu, Apr 05, 2007 at 06:27:08PM -0400, Lennart Sorensen wrote:
> I will test that out on my 486 and see if that works.  It is certainly
> much nicer, so assuming it works I vote for this one instead.

It works perfectfly.  Given I see the linux kernel does the same thing,
I guess that isn't surprising at all.

--
Len Sorensen


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

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Lennart Sorensen]

On Thu, Apr 05, 2007 at 06:59:16PM -0400, Lennart Sorensen wrote:
> My 486 actually does a useful job, and hence usually runs pure stable.
> I figured I would upgrade it to see if anything broken, and boy did it
> ever break.  It is a good old reliable machine and the only 486 I have.
> I guess loosing proftpd and php isn't the worst things that can happen,
> although I do like my ftp server to work, as well as my web server.  At
> least I know have a fixed version installed so my machine works.
> 
> Maybe I am the only person left with a 486 doing useful work, but it has
> run problem free for 15 years now and shows no signs of giving any.
> Hopefully I will replace the 486 with a ppro in the next few months, in
> which case the 486 will become available for me to just do tests on and
> other experiments.

I guess I can add that given the mysql was the only real problem I
encountered upgrading, Etch looks to be in pretty darn good shape.  The
other minor problems was the netscape navigator 4.77 packages breaking
the x.org /usr/X11R6 upgrade.  I didn't realize they were still
installed.  I guess starting out with Debian 2.1, and upgrading over the
years you end up with a bit of garbage left installed.  I should check
for obsolete packages and clean them out more often.  Thanks to all the
great maintainers that have made it possible to never have to reinstall
in 8 years of service.

--
Len Sorensen


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

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Steve Langasek]

On Thu, Apr 05, 2007 at 06:59:16PM -0400, Lennart Sorensen wrote:
> > In practical terms, it seems to me that part of the fix here should really
> > be to declare that we don't officially support 486 CPUs anymore, since no
> > one who is using one was involved enough in the etch release to have
> > documented this bug as RC until three days before release. :P

> My 486 actually does a useful job, and hence usually runs pure stable.
> I figured I would upgrade it to see if anything broken, and boy did it
> ever break.  It is a good old reliable machine and the only 486 I have.
> I guess loosing proftpd and php isn't the worst things that can happen,
> although I do like my ftp server to work, as well as my web server.  At
> least I know have a fixed version installed so my machine works.

> Maybe I am the only person left with a 486 doing useful work, but it has
> run problem free for 15 years now and shows no signs of giving any.
> Hopefully I will replace the 486 with a ppro in the next few months, in
> which case the 486 will become available for me to just do tests on and
> other experiments.

Well, on that subject c.f.
. :)

> Is there any good reason 486s should not be supproted anymore?  I know
> why 386s are not supported anymore.

Like I said, in practical terms, if a bug like this in a major server
package goes unnoticed until 3 days before the release, we are not actually
"supporting" 486.  We support the i386 architecture quite well, but it seems
only honest to admit that as a project, we don't care about 486 enough to
even get 486-specific problems marked as RC in time to do anything about
them for a release.

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


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

Re: MySql broken on older 486 and other cpuid less CPUs. Does this qualify as RC?

[Julien Cristau]

On Thu, Apr  5, 2007 at 19:08:03 -0400, Lennart Sorensen wrote:

> The other minor problems was the netscape navigator 4.77 packages
> breaking the x.org /usr/X11R6 upgrade.

Do you know the exact name of the old package that caused this problem?

Thanks,
Julien


signature.asc
Description: Digital signature

Re: net-tools maintenance status

[Martín Ferrari]

I'm copying Olaf, since he asked for it in the OP, and Bernd, since
he's the maintainer.

On 4/3/07, Michael Banck <[EMAIL PROTECTED]> wrote:

Hi,

On Tue, Apr 03, 2007 at 02:09:00PM +0200, Olaf van der Spek wrote:
> On 8/2/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> >What's the maintenance status of the net-tools package?

Are you applying for co-maintenance?  If so, you should rather talk the
the package maintainer, I think.  Alternatively, you could do some bug
triaging and/or trying to reproduce the older bugs, if you haven't done
so already.


I don't know if I will be able to apply for co-maint, but I started
working a little on triaging. Hope it helps.

--
Martín Ferrari

Work-needing packages report for Apr 6, 2007

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 380 (new: 15)
Total number of packages offered up for adoption: 82 (new: 1)
Total number of packages requested help for: 39 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   bombermaze (#417824), orphaned yesterday
 Description: A bomberman clone for GNOME, for 2-4 players
 Installations reported by Popcon: 138

   centericq (#416958), orphaned 5 days ago
 Description: A text-mode multi-protocol instant messenger client
 Reverse Depends: centericq centericq-fribidi centericq-utf8
 Installations reported by Popcon: 757

   egoboo (#416953), orphaned 5 days ago
 Description: 3D dungeon crawling adventure in the spirit of NetHack
 Installations reported by Popcon: 343

   egoboo-data (#416957), orphaned 5 days ago
 Description: Egoboo data files
 Reverse Depends: egoboo
 Installations reported by Popcon: 356

   gmessage (#417825), orphaned yesterday
 Description: an xmessage clone based on GTK+
 Reverse Depends: kvdr
 Installations reported by Popcon: 611

   gobo (#416959), orphaned 5 days ago
 Description: Portable Eiffel tools and libraries
 Installations reported by Popcon: 30

   mlmmj (#417827), orphaned yesterday
 Description: mail server independent mailing list manager
 Reverse Depends: dtc dtc-postfix-courier mlmmj-php-web-admin
   python-mlmmjadmd
 Installations reported by Popcon: 25

   mutt-ng (#416860), orphaned 6 days ago
 Description: text-based mailreader supporting MIME, GPG, PGP and
   threading
 Installations reported by Popcon: 153

   orgadoc (#416956), orphaned 5 days ago
 Description: Organizes documents from XML descriptions
 Installations reported by Popcon: 24

   rigel (#417828), orphaned yesterday
 Description: a personal information manager for X
 Installations reported by Popcon: 27

   stunnel (#416955), orphaned 5 days ago
 Description: Universal SSL tunnel for network daemons
 Installations reported by Popcon: 747

   stunnel4 (#416961), orphaned 5 days ago
 Description: Universal SSL tunnel for network daemons
 Installations reported by Popcon: 355

   tcltls (#417832), orphaned yesterday
 Description: The TLS OpenSSL extension to Tcl
 Reverse Depends: amsn
 Installations reported by Popcon: 1987

   ubh (#417833), orphaned yesterday
 Description: Download and decode Usenet binaries
 Installations reported by Popcon: 76

   xpad (#417830), orphaned yesterday
 Description: sticky note application for X
 Installations reported by Popcon: 177

365 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   chromium (#417805), offered yesterday
 Description: Fast paced, arcade-style, scrolling space shooter
 Reverse Depends: chromium-data
 Installations reported by Popcon: 340

81 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 651 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client
 Installations reported by Popcon: 65

   apt-build (#365427), requested 341 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 674

   apt-cacher (#403584), requested 108 days ago
 Description: caching proxy system for Debian package and source
   files
 Installations reported by Popcon: 284

   apt-show-versions (#382026), requested 240 days ago
 Description: lists available package versions with distribution
 Installations reported by Popcon: 2338

   athcool (#278442), requested 891 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 258

   audacity (#397166), requested 151 days ago
 Description: looking for co-maintainer
 Installations reported by Popcon: 2918

   cdw (#398252), requested 144 days ago
 Description: Tool for burning CD's - console version
 Reverse Depends: cdw gcdw
 Installations reported by Popcon: 238

   cvs (#354176), requested 406 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (17
   more o