Re: Accepted lynx 2.8.5-2sarge2.2 (source i386)

[Thomas Dickey]

On Mon, Nov 27, 2006 at 10:00:40AM +0100, Andreas Barth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Format: 1.7
> Date: Mon, 27 Nov 2006 07:43:17 +0100
> Source: lynx
> Binary: lynx
> Architecture: source i386
> Version: 2.8.5-2sarge2.2
> Distribution: unstable
> Urgency: low
> Maintainer: James Troup <[EMAIL PROTECTED]>
> Changed-By: Andreas Barth <[EMAIL PROTECTED]>
> Description: 
>  lynx   - Text-mode WWW Browser
> Closes: 396964
> Changes: 
>  lynx (2.8.5-2sarge2.2) unstable; urgency=low
>  .
>* Non-maintainer upload.
>* Read user configuration from home directory, not current
>  working directory. Closes: #396964
>  Thanks to Tom Parker for the patch.

There's no possibility of including that patch upstream.

See

http://lynx.isc.org/lynx2.8.5/patches/

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpApTpOADLxC.pgp
Description: PGP signature

Re: Accepted lynx 2.8.5-2sarge2.2 (source i386)

[Guus Sliepen]

On Thu, Nov 30, 2006 at 06:41:21AM -0500, Thomas Dickey wrote:

> > Changes: 
> >  lynx (2.8.5-2sarge2.2) unstable; urgency=low
> >  .
> >* Non-maintainer upload.
> >* Read user configuration from home directory, not current
> >  working directory. Closes: #396964
> >  Thanks to Tom Parker for the patch.
> 
> There's no possibility of including that patch upstream.

So what? If upstream does not want to accept a patch that fixes a
security bug (which #396964 is, if I read it correctly), that's their
problem. Debian often releases packages with patches that are not
accepted by upstream, for various reasons.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Accepted lynx 2.8.5-2sarge2.2 (source i386)

[Thomas Dickey]

On Thu, Nov 30, 2006 at 12:47:26PM +0100, Guus Sliepen wrote:
> On Thu, Nov 30, 2006 at 06:41:21AM -0500, Thomas Dickey wrote:
> 
> > > Changes: 
> > >  lynx (2.8.5-2sarge2.2) unstable; urgency=low
> > >  .
> > >* Non-maintainer upload.
> > >* Read user configuration from home directory, not current
> > >  working directory. Closes: #396964
> > >  Thanks to Tom Parker for the patch.
> > 
> > There's no possibility of including that patch upstream.
> 
> So what? If upstream does not want to accept a patch that fixes a

so what?  Read the patch.  You certainly didn't, or if you _did_ you
understand nothing of the change.

The patch breaks existing functionality (hardcodes one of the configurable
selections).

regards.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpRJHcjMkTnp.pgp
Description: PGP signature

Re: Naming a 32-bit/64-bit specific Java package

[Goswin von Brederlow]

Ola Lundqvist <[EMAIL PROTECTED]> writes:

> Hi
>
> On Tue, Nov 28, 2006 at 01:41:22PM +, Matthew Johnson wrote:
>> Is it possible to upload two different versions of the any package to
>> the different architectures? So that you get the -64 version on 64bit
>> archs and the -32 version on 32 bit archs? It's definitely possible to
>> have different versions in the archive for different architectures.
>
> Not unless you make them arch specific, and then you do not really have any
> benefit from it anyway.
>
> If you have defined it arch: all, then that means that it will work
> on _all_ architectures (if you have fullfilled the dependencies).
> If you have something that depend on 32 vs 64 bit then it is not
> architecture independent.
>
> We could of course try to optimize and introduce a new category
> 32 bit and 64 bit, but I do not think it is that interesting to have
> that, especially if it is just a few (or one) package there.

We already have several arch:all packages that are architecture
specific for its use. You can install them everywhere (if depends even
allow that) but they won't be of use there. We also have arch:all
packages that have unfullfillable depends on some archs.

It is relatively simple to ensure the user gets the right falvour of
the package installed by using the proper depends line in the
application or through a meta pacakage that pulls in just the right
one. The details of having a -32 and -64 package will be hidden from
the user unless seh looks closely.

> Regards,
>
> // Ola

MfG
Goswin


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

Re: Ftpmaster bug reports are not processed nearly fast enough.

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Michael Banck ([EMAIL PROTECTED]) [061129 13:50]:
>> On Tue, Nov 28, 2006 at 11:06:55PM -0500, Nathanael Nerode wrote:
>> > As for the bugs requesting change of priorities in the Overrides
>> > file, many appear to simply be ignored permanently. #263887 is the
>> > canonical example.  I recommend eliminating the overrides file for
>> > packages of priority 'standard' and lower, and instead always
>> > allowing package maintainers to set their own package priority among
>> > 'extra', 'optional', and 'standard', 
>> 
>> As `standard' is what some front ends still install by default AFAIK,
>> this might lead to bloat when more and more maintainers think their
>> package really should be standard.
>
> For standard, that seems like a bad idea. For extra and optional (and
> also sections), a half-override database could make sense, i.e.
> overrides are only taken from the database if the database has an entry,
> and the database doesn't have an entry usually, and also entries are
> purged (normally) in case package and database agree (so that ftp-team
> could easily move packages around, but once the package maintainer has
> caught up with the database, the maintainer is responsible for future
> sections).

So I change the priority to what ftpmaster thinks, wait a month for
the entry to get purged and then change it back to what I think and
get it?

Purging sounds dangerous. :)

MfG
Goswin


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

Re: Accepted lynx 2.8.5-2sarge2.2 (source i386)

[Guus Sliepen]

On Thu, Nov 30, 2006 at 07:00:14AM -0500, Thomas Dickey wrote:

> > > There's no possibility of including that patch upstream.
> > 
> > So what? If upstream does not want to accept a patch that fixes a
> 
> so what?  Read the patch.  You certainly didn't, or if you _did_ you
> understand nothing of the change.
> 
> The patch breaks existing functionality (hardcodes one of the configurable
> selections).

I didn't know PERSONAL_MAILCAP was run-time configurable (it looks
a #define to me). If apt-get source wasn't segfaulting at the moment I'd
check it. But this explaination is a lot more useful than "upstream
won't accept it". But why did you send this to the debian-devel mailing
list instead of as a follow-up to the bugreport?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Ftpmaster bug reports are not processed nearly fast enough.

[Andreas Barth]

* Goswin von Brederlow ([EMAIL PROTECTED]) [061130 13:44]:
> So I change the priority to what ftpmaster thinks, wait a month for
> the entry to get purged and then change it back to what I think and
> get it?

I would consider this as abuse, and also, that was the reason why I
wrote "(normally)".


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Conditionally applying an architecture-dependent patch

[Goswin von Brederlow]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> I need exactly the same thing. I was lloking for an include statement
>> for series files though. Something like
>
>> debian/patches/series.common:
>> version.patch
>> foo.patch
>> barf.patch
>
>> debian/patches/series.amd64:
>> #include "series.common"
>> amd64.patch
>
>> debian/patches/series.i386:
>> #include "series.common" 
>> i386.patch 
>
>> Quilt does not seem to have this. But it shouldn't be hard to write a
>> makefile target that creates the series file by running
>> debian/patches/series.$ARCH through cpp. That is the way I'm going
>> anyway, hence the syntax.
>
> That seems like overkill.  Why not just do:
>
> ARCH := $(shell dpkg-architecture -qDEB_BUILD_ARCH)
>
> patch: patch-stamp
> patch-stamp:
>   cp debian/patches/series.common debian/patches/series
>   set -e; if [ -f debian/patches/series.$(ARCH) ] ; then \
>   cat debian/patches/series.$(ARCH) >> debian/patches/series ; \
>   fi
>   quilt push -a || test $$? == 2
>   touch patch-stamp
>
> and remove debian/patches/series in unpatch?

That isn't very flexible.

By using cpp I can use #include recursively and at any point of the
series. I can also use #ifdef or any other cpp construct. I can insert
an architecture specific patch by enclosing it in #ifdef __arch__. If
I cat the files together I would have to split files into smaller
chunks.

Obviously I hope that quilt includes a feature like include and even
conditional patches in the future.

MfG
Goswin


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

Re: Accepted lynx 2.8.5-2sarge2.2 (source i386)

[Thomas Dickey]

On Thu, Nov 30, 2006 at 01:46:31PM +0100, Guus Sliepen wrote:
> I didn't know PERSONAL_MAILCAP was run-time configurable (it looks
> a #define to me). If apt-get source wasn't segfaulting at the moment I'd

It's a #define.  But the change to use the home directory is in the
wrong place.  I'd point out that it doesn't solve the problem, and
that the program is still subject to the same issue as reported, but
that would be redundant.

> check it. But this explaination is a lot more useful than "upstream
> won't accept it". But why did you send this to the debian-devel mailing
> list instead of as a follow-up to the bugreport?

I've noticed that my comments to followup on the lynx bug reports are
ignored by the package maintainer as well as the security team.

It's nice to get replies.  (And normally expected that one or both of
those would solicit comments from upstream).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpIERS03otZj.pgp
Description: PGP signature

Re: Accepted lynx 2.8.5-2sarge2.2 (source i386)

[Andreas Barth]

* Thomas Dickey ([EMAIL PROTECTED]) [061130 14:12]:
> On Thu, Nov 30, 2006 at 01:46:31PM +0100, Guus Sliepen wrote:
> > I didn't know PERSONAL_MAILCAP was run-time configurable (it looks
> > a #define to me). If apt-get source wasn't segfaulting at the moment I'd
> 
> It's a #define.  But the change to use the home directory is in the
> wrong place.  I'd point out that it doesn't solve the problem, and
> that the program is still subject to the same issue as reported, but
> that would be redundant.

So, what do you think would be the appropriate behaviour? I don't mind
changing the behaviour to something which sounds sensible for you too,
but - taking the files from the cwd opens up a can of issues.


> I've noticed that my comments to followup on the lynx bug reports are
> ignored by the package maintainer as well as the security team.

I'm sorry, but I didn't see any comments from you on this bug report -
though perhaps I didn't look deep enough.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Bug#98549: Canad!an Pharnnacy,Jamil Dhaouadi

[john d stewart]

Hey,bud,happy holiday.
 
http://forusmedz.com
 
-
DEMANDTEC EMAIL NOTICE:

NOTICE: This email transmission and all attached files contain information 
intended for the designated individual or entity to whom it is addressed and 
may contain information that is proprietary, privileged and/or exempt from 
disclosure under applicable law. If you are not the intended recipient or an 
employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any dissemination, distribution, 
copying, or other use of this email or its attachments is strictly prohibited. 
If you have received this email in error, please notify the sender immediately 
by replying to this message and please delete the original message without 
making any copies. 


WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. Although we 
have taken reasonable precautions to ensure that this email and all attachments 
are free from viruses, we accept no liability for any loss or damage arising 
from the use of this email or its attachments. 

Jose Martinez
Ernest Reid
mike m ioannou
nagamani Yarra
Frank Clary
T M STADE
Susan McHugh
Danielle Clymer



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

Re: Accepted lynx 2.8.5-2sarge2.2 (source i386)

[Thomas Dickey]

On Thu, Nov 30, 2006 at 02:15:42PM +0100, Andreas Barth wrote:
> * Thomas Dickey ([EMAIL PROTECTED]) [061130 14:12]:
> > On Thu, Nov 30, 2006 at 01:46:31PM +0100, Guus Sliepen wrote:
> > > I didn't know PERSONAL_MAILCAP was run-time configurable (it looks
> > > a #define to me). If apt-get source wasn't segfaulting at the moment I'd
> > 
> > It's a #define.  But the change to use the home directory is in the
> > wrong place.  I'd point out that it doesn't solve the problem, and
> > that the program is still subject to the same issue as reported, but
> > that would be redundant.
> 
> So, what do you think would be the appropriate behaviour? I don't mind
> changing the behaviour to something which sounds sensible for you too,
> but - taking the files from the cwd opens up a can of issues.

yes - I agreed with that, but also pointed out that there wasn't a check
to ensure that the file is not world-writable, etc.  That's something
that the various shell programs do for example - iirc csh won't use
.cshrc if you don't own it (for at least some systems ;-).

It would be nice to ensure that the global mailcap/mime.types files also
are secure, but that's harder to do (portably) since you can't assume
much about the ownership of the file.  But I did at least ensure that
those are absolute pathnames.

> > I've noticed that my comments to followup on the lynx bug reports are
> > ignored by the package maintainer as well as the security team.
> 
> I'm sorry, but I didn't see any comments from you on this bug report -
> though perhaps I didn't look deep enough.

It was moved from another number, where I pointed out that most of the
given examples were still true for the user's home directory.  However,
my remark about ignored comments applies to last couple of years.

Anyway, compare with the patch I made a couple of weeks ago.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgpF7svEfZzb7.pgp
Description: PGP signature

Re: Conditionally applying an architecture-dependent patch

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> That isn't very flexible.

> By using cpp I can use #include recursively and at any point of the
> series. I can also use #ifdef or any other cpp construct. I can insert
> an architecture specific patch by enclosing it in #ifdef __arch__. If
> I cat the files together I would have to split files into smaller
> chunks.

Oh, well, yeah, if you want to do all that sort of stuff, I suppose cpp
makes sense.  I've never had a need to get that complicated, but, well,
YMMV.

I hate using cpp for anything other than C code because of all the
tokenizing that it does that's rather specific to C's syntax, but I
suppose if imake got away with it (mostly) for years, somethinga s simple
as the series file is probably okay.

> Obviously I hope that quilt includes a feature like include and even
> conditional patches in the future.

That's aesthetically unappealing to me, so I see why the quilt upstream
possibly hasn't done something like that yet.  There's a certain
simplicity to saying that quilt just uses your series file, and how you
construct that file is up to you.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Ftpmaster bug reports are not processed nearly fast enough.

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow ([EMAIL PROTECTED]) [061130 13:44]:
>> So I change the priority to what ftpmaster thinks, wait a month for
>> the entry to get purged and then change it back to what I think and
>> get it?
>
> I would consider this as abuse, and also, that was the reason why I
> wrote "(normally)".
>
>
> Cheers,
> Andi
> -- 
>   http://home.arcor.de/andreas-barth/

No kidding. :)

MfG
Goswin


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

Re: Hijacking ITA: sa-exim

[Magnus Holmgren]

Another three weeks have passed. I give Anand a last chance to respond as I at 
the same time CC [EMAIL PROTECTED]

On Friday 10 November 2006 13:23, Magnus Holmgren wrote:
> sa-exim was [1]orphaned on February 12. Four days later, Anand Kumria
> announced his ITA, but he never completed the adoption and hasn't responded
> to several mails about the issue. He doesn't seem to be MIA though; he has
> uploaded at least one [2]package pretty recently. That was before I mailed
> him myself, though...
>
>  [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352533
>  [2] http://packages.qa.debian.org/g/gtk-gnutella.html
>
> Can I take this package anyway? I use it since I feel it still has
> something Exim's built-in "spam" ACL condition (also known as exiscan)
> doesn't offer; namely, more flexibility in the adding of X-Spam headers.

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


pgpLzTSeSP4eq.pgp
Description: PGP signature

BTS: Why no "invalid" or "notabug" tag?

[Magnus Holmgren]

http://www.debian.org/Bugs/Developer defines the following tags as reasons to 
dismiss a bug report:

* wontfix: the behaviour described can be reproduced or the feature request is 
understood; it is indeed an issue with our package but we can't or won't do 
anything about it because there are stronger reasons to leave things the way 
they are.

* unreproducible: the behaviour described could not be reproduced or the 
feature requested already exists.

But what about the middle case, i.e. "the behaviour described could be 
reproduced, but it's not a bug, or at least not our fault"? (Bugzilla calls 
this "INVALID").

Often, but not always, the bug can or should be reassigned to another package, 
but then a second user might come around and submit the same bug report.

Example: http://bugs.debian.org/400437 and http://bugs.debian.org/400693

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


pgpufrZsDze9G.pgp
Description: PGP signature

Re: BTS: Why no "invalid" or "notabug" tag?

[Marco d'Itri]

On Nov 30, Magnus Holmgren <[EMAIL PROTECTED]> wrote:

> But what about the middle case, i.e. "the behaviour described could be 
> reproduced, but it's not a bug, or at least not our fault"? (Bugzilla calls 
> this "INVALID").
I agree that it could be useful, since I get a lot of these cases...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Etch, apache-perl and php5 needs manual config

[Patrick Frank]

Hello.

after a base install of Debian Etch, I selected all necessary packages
for a LAMP System - Linux Apache MySQL PHP.

Specifically:

apache-perl  1.3.34-4
php5  5.1.6-5
libapache-mod-php5  5.1.6-5
[and related packages]

But I have to manually edit /etc/apache-perl/httpd.conf and enable
"AddType application/x-httpd-php .php" aswell as
/etc/apache-perl/modules.conf
to add "LoadModule php5_module /usr/lib/apache/1.3/libphp5.so".

Why do the installer scripts not handle that automatically?

That could avoid a lot of noise on support forums of all kind ...

--

greetings,
Patrick Frank

Re: Etch, apache-perl and php5 needs manual config

[Russ Allbery]

Patrick Frank <[EMAIL PROTECTED]> writes:

> after a base install of Debian Etch, I selected all necessary packages
> for a LAMP System - Linux Apache MySQL PHP.

> Specifically:

> apache-perl  1.3.34-4

If at all possible, I strongly encourage you to use Apache 2.2 instesad of
Apache 1.x.  Apache 1.x is nearly unsupported and is certainly not
undergoing any further development, and module and site configuration in
Apache 2.2 is much cleaner.

Already some third-party modules do not support Apache versions prior to
2.0 at all.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Etch, apache-perl and php5 needs manual config

[Steve Kemp]

On Thu, Nov 30, 2006 at 07:48:40PM +0100, Patrick Frank wrote:

>But I have to manually edit /etc/apache-perl/httpd.conf and enable
>"AddType application/x-httpd-php .php" aswell as
>/etc/apache-perl/modules.conf
>to add "LoadModule php5_module /usr/lib/apache/1.3/libphp5.so".
> 
>Why do the installer scripts not handle that automatically?

  They would if you used the more recent Apache 2.x or 2.2.x packages.

  (In that case you'd use the utility helper script "a2enmod" and
 "a2dismod" to enable/disable a module, and that would happen
 automatically for the majority of modules.  Certainly for
 PHP.)

Steve
-- 


signature.asc
Description: Digital signature

Re: BTS: Why no "invalid" or "notabug" tag?

[Darren Salt]

I demand that Magnus Holmgren may or may not have written...

[snip]
> Often, but not always, the bug can or should be reassigned to another
> package, but then a second user might come around and submit the same bug
> report.

Then, when showing bugs for that package, shouldn't those reassigned bugs
still be listed (under a "reassigned" heading)?

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Say NO to UK ID cards. http://www.no2id.net/

Invention: the solar-powered torch.


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

Re: Etch, apache-perl and php5 needs manual config

[sean finney]

hi patrick,

On Thu, 2006-11-30 at 19:48 +0100, Patrick Frank wrote:

> apache-perl  1.3.34-4
> php5  5.1.6-5
> libapache-mod-php5  5.1.6-5
> [and related packages]
> 
> But I have to manually edit /etc/apache-perl/httpd.conf and enable
> "AddType application/x-httpd-php .php" aswell
> as /etc/apache-perl/modules.conf
> to add "LoadModule php5_module /usr/lib/apache/1.3/libphp5.so". 
> 
> Why do the installer scripts not handle that automatically?

they do, actually.  the version you've specifically installed didn't,
but that was a bug and it's been fixed for a couple weeks now.  in fact
i think the fix has finally made it to etch (5.2.0-something).


sean


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

Re: BTS: Why no "invalid" or "notabug" tag?

[Don Armstrong]

On Thu, 30 Nov 2006, Magnus Holmgren wrote:
> what about the middle case, i.e. "the behaviour described could be
> reproduced, but it's not a bug, or at least not our fault"?
> (Bugzilla calls this "INVALID").
>
> Often, but not always, the bug can or should be reassigned to another 
> package, 
> but then a second user might come around and submit the same bug report.

At least one of the bugs should be reassigned; you can of course clone
a bug, reassign it, make the original blocking on the reassigned bug,
and retitle the original to indicate what is the problem. [There is a
wishlist bug about adding some sort of trail that indicates that a bug
has been reassigned, but don't hold your breath for that to happen any
time soon.]

As far as what has to happen before a notabug or notbug or invalid or
yourfavoriteunsupported tag is considered (by me, anyway), see #376594
and my responses.

As a final note, using usertags to handle this sort of situtation is
quite easy:

user [EMAIL PROTECTED]
usertag 400693 notabug
thanks


Don Armstrong

-- 
"I'm a rational being--of a sort--rational enough, at least, to see the
symptoms of insanity around me. And I'm human, the same as the poeple
I think of as victims when my guard drops. It's at least possible I'm
even crazier than my fellows, whom I'm tempted to pity.
"There seems only one thing to do, and that's get drunk"
 -- Chad C. Mulligan (John Brunner _Stand On Zanzibar p390)

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


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

Work-needing packages report for Dec 1, 2006

[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: 331 (new: 11)
Total number of packages offered up for adoption: 87 (new: 3)
Total number of packages requested help for: 35 (new: 0)

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



The following packages have been orphaned:

   fbdesk (#400359), orphaned 5 days ago
 Description: desktop icons for fluxbox window manager
 Installations reported by Popcon: 356

   id3tool (#400360), orphaned 5 days ago
 Description: A command line editor for id3 tags.
 Installations reported by Popcon: 336

   klineakconfig (#401134), orphaned today
 Installations reported by Popcon: 124

   ksimus-floatingpoint (#401135), orphaned today
 Installations reported by Popcon: 371

   libapache-miniwiki-perl (#400362), orphaned 5 days ago
 Description: Miniature Wiki for Apache
 Installations reported by Popcon: 23

   libheap-perl (#400366), orphaned 5 days ago
 Description: Perl extensions for keeping data partially sorted
 Reverse Depends: libcache-perl libgraph-perl
 Installations reported by Popcon: 151

   libmath-round-perl (#400367), orphaned 5 days ago
 Description: Perl extension for rounding numbers
 Reverse Depends: horae libwww-myspace-perl slimscrobbler
 Installations reported by Popcon: 96

   libnet-ident-perl (#400364), orphaned 5 days ago
 Description: lookup the username on the remote end of a TCP/IP
   connection
 Installations reported by Popcon: 599

   librcs-perl (#400365), orphaned 5 days ago
 Description: Front end to revision control utilities for perl
 Reverse Depends: libapache-miniwiki-perl
 Installations reported by Popcon: 42

   libtext-shellwords-perl (#400368), orphaned 5 days ago
 Description: Tokenises lines of text
 Installations reported by Popcon: 50

   python-uncertainities (#401136), orphaned today
 Installations reported by Popcon: 182

320 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:

   wmcpu (#400943), offered yesterday
 Description: Window Maker docking app similar to xosview
 Installations reported by Popcon: 212

   wmdate (#400944), offered yesterday
 Description: Calendar for window manager docking bars
 Installations reported by Popcon: 231

   wmscope (#400945), offered yesterday
 Description: Graphical representation of sound waves in a dockapp
 Installations reported by Popcon: 32

84 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 525 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client
 Installations reported by Popcon: 52

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

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

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

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

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

   cvs (#354176), requested 280 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (16
   more omitted)
 Installations reported by Popcon: 9259

   docbook (#358522), requested 253 days ago
 Description: standard SGML representation system for technical
   documents
 Reverse Depends: alcovebook-sgml docbook-dsssl docbook-to-man
   sgmltools-lite
 Installations reported by Popcon: 3513

   docbook-xml (#358520), requested 253 days ago
 Description: standard XML documentation system, for software and
   systems
 Reverse Depends: dblatex docbook-dsssl docbook-ebnf
   docbook-html-forms docbook-jrefentry docbook-mathml docbook-simple
   docbook-slides docbook-website docbook-xsl-stylesheets-ko (6 more
   omit