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

2006-12-04 Thread Don Armstrong 
On Mon, 04 Dec 2006, Marc Haber wrote:
> Has blocking been documented since I looked for the last time?

Blocking has been documented for quite some time:

revision 1.54
date: 2006-07-13 15:14:12 -0700;  author: joeyh;  state: Exp;  lines: +7 -0
document block/unblock

 

Don Armstrong

-- 
I'd never hurt another living thing.
But if I did...
It would be you.
 -- Chris Bishop  http://www.chrisbishop.com/her/archives/her69.html

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


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

Why not scan for unmaintained packages and orphan them?

2006-12-04 Thread Eduard Bloch 
#include 
* Marc Haber [Mon, Dec 04 2006, 08:51:51AM]:
> On Thu, 30 Nov 2006 18:05:21 +0100, [EMAIL PROTECTED] (Marco d'Itri) wrote:
> >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...
> 
> Why does that matter? You close everything that is not clearly a bug
> anyway, immediately.

It is not always clearly. Sometimes time or a good opportunity is needed
to reproduce an issue, even if the description is clear enough.

Unfortunately, there are maintainers that prefer to let such bug reports
rot instead of tagging them as seen|pending|help|wontfix|moreinfo|... .
I don't like such behaviour, it is not nice to the bugreporters (*).
Why should they do the work and collect all relevant data just to be
ignored? It is easier to fix the small problem with some dirty local
hack and let the Debian upstream do what they do. They won't care about
problems of lame users anyway.

And a deliberate decission to ignore bug reports in this way is IMHO
an act against the social contract. Such maintainers should realize that
they are sabotaging the project and look for comaintainers or new
maintainers or just orphan the package.

What I would like to do is going with a big axe trough the BTS, send a
ping mail (**) to bug reports that have visibly not received any
attention of the corresponding package maintainer. And if no reaction is
visible after few weeks, just automaticaly hijack/orphan such packages.

And no, I won't tell you names.

(*) Even if those problem are not grave/serious, or require work (oooh)
for reproducing. Or if a such bug report does not contain a perfect patch
already. Putting complicated (time consuming) things of is a human way
to deal with new tasks, but it is the way of the lazy ones. Or those who
can not admit that they are not able to do expected work because of
missing spare time but collect big packages to maintain the own ego.

(**) Like: "Hello, this is the automatic bug-system scanner. It became
evident that this bug report has not been processed by you, it is not
tagged with "seen" or any other tag indicating real activity. Please
change the state of this bug report appropriately if you do care about
your package."

Eduard.
-- 
Ein Schmeichler ist's selten aus bloßem Eigennutz, sondern aus
Charakter; denn er schmeichelt Niedrigen wie Hohen.
-- Jean Paul


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

Re: package update policy

2006-12-04 Thread Andreas Barth 
* Russ Allbery ([EMAIL PROTECTED]) [061203 20:48]:
> Ritesh Raj Sarraf <[EMAIL PROTECTED]> writes:
> 
> > I just wanted to know if Debian has a policy (timeline) for inclusion of
> > a newer release of a software.
> 
> No, it doesn't.
> 
> Individual maintainers may set such a policy for their own packages, but
> Debian has no distribution-wide policy on how fast newer releases of
> software are included.  It's not really possible to set such a policy
> across the board; sometimes one never wants to incorporate a newer release
> of a piece of software for some reason.

(I couldn't resist nit-picking, sorry)

With the exception that release policy specifies:
| 5. General
|
|  (a) Supportable
|
|Packages in the archive must not be so buggy or out of date we
|refuse to support them.

But of course, what that means can be quite different in different
cases - so in the end, it is (mostly) the maintainers decision (as you
wrote).


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


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

Re: Mass closing of bugs ?

2006-12-04 Thread Filipus Klutiero 
Do you have an estimation of the proportion of bugs that should be open? If 
less than half of bugs not found in a version ulterior to some version should 
be open, closing these bugs sounds like an idea. It would be less rude to 
first warn about the upcoming closure and ask owners to mark these bugs as 
found in the current version if they're reproducible there. To make it easier 
for owners to test iceape, please wait for it to be in testing before sending 
these messages (if you decide to procede this way).


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

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

2006-12-04 Thread Marc Haber 
On Mon, 4 Dec 2006 00:30:40 -0800, Don Armstrong <[EMAIL PROTECTED]>
wrote:
>On Mon, 04 Dec 2006, Marc Haber wrote:
>> Has blocking been documented since I looked for the last time?
>
>Blocking has been documented for quite some time:
>
>revision 1.54
>date: 2006-07-13 15:14:12 -0700;  author: joeyh;  state: Exp;  lines: +7 -0
>document block/unblock

The important information (which file was modified) is missing here.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Bug#401578: ITP: libfilter-template-perl -- Source filter for inline code templates (macros)

2006-12-04 Thread Gunnar Wolf 
Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf <[EMAIL PROTECTED]>

* Package name: libfilter-template-perl
  Version : 1.02
  Upstream Author : Rocco Caputo <[EMAIL PROTECTED]>, Matt Cashner
* URL : http://www.cpan.org/modules/by-module/Filter/
* License : GPL + Artistic
  Programming Lang: Perl
  Description : Source filter for inline code templates (macros)

Source filter for Perl, allowing to specify inline source code
templates. Templates can be much faster than subroutines, but they can
mean a much harder debugging, maintenance and use - Read the
documentation and choose wisely. 

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: Bonsai: Candidate for removal from the archive?

2006-12-04 Thread Steve Langasek 
On Mon, Dec 04, 2006 at 02:45:26AM +, Stephen Gran wrote:

> > > Why exactly do you need a pre-depends to use a perl module in postinst?

> > Because:

> > [EMAIL PROTECTED]:/tmp/bonsai-1.3+cvs20060111/debian$ grep use.*File 
> > bonsai.postinst 
> > use File::Find;

> > The postinst is a Perl file.

> You need Pre-Depends only when a package must be configured before your
> postinst is run.  In the case of a perl module, I would think it only
> needs to be unpacked.

No, you need a Pre-Depends only when a package must be configured before
your *preinst* is run.  Packages are always configured in dependency order.

-- 
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: BTS: Why no "invalid" or "notabug" tag?

2006-12-04 Thread Roberto C. Sanchez 
On Mon, Dec 04, 2006 at 08:51:51AM +0100, Marc Haber wrote:
> On Thu, 30 Nov 2006 18:05:21 +0100, [EMAIL PROTECTED] (Marco d'Itri) wrote:
> >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...
> 
> Why does that matter? You close everything that is not clearly a bug
> anyway, immediately.
> 

You mean so that different  people can file the same bug over and over
again?  Personally, I'd like to see a notabug tag so that you can have a
bug still appear on the BTS page but not count (maybe even put the
notabug bugs at the top or after the RC bugs).  Then people will see
them and you can have some sort of explanation attached so that people
can see why the maintainer does not consider it a bug.

Regards,

-Roberto
-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


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

Re: Bonsai: Candidate for removal from the archive?

2006-12-04 Thread Marc 'HE' Brockschmidt 
Gunnar Wolf <[EMAIL PROTECTED]> writes:
> Marc 'HE' Brockschmidt dijo [Sun, Dec 03, 2006 at 11:47:45AM +0100]:
 use File::Find;
>>> Provided by perl-modules, which is build-essential. However, this
>>> module is used at installation time (in postinst), so yes, this should
>>> be listed as a pre-depends (as it's not a required/essential package)
>> Why exactly do you need a pre-depends to use a perl module in postinst?
> Because:
>
> [EMAIL PROTECTED]:/tmp/bonsai-1.3+cvs20060111/debian$ grep use.*File 
> bonsai.postinst 
> use File::Find;
>
> The postinst is a Perl file.

So what? When the postinst is run, dependencies are unpacked and
installed, though they may not be configured. File::Find can be used
without configuring the perl-modules package, so a dependency is enough
to use it.

Marc
-- 
BOFH #204:
Just pick up the phone and give modem connect sounds. "Well you said
we should get more lines so we don't have voice lines."


pgpfxiJ1ERnnv.pgp
Description: PGP signature

Re: Bonsai: Candidate for removal from the archive?

2006-12-04 Thread Marc 'HE' Brockschmidt 
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Mon, Dec 04, 2006 at 02:45:26AM +, Stephen Gran wrote:
>> You need Pre-Depends only when a package must be configured before your
>> postinst is run.  In the case of a perl module, I would think it only
>> needs to be unpacked.
> No, you need a Pre-Depends only when a package must be configured before
> your *preinst* is run.  Packages are always configured in dependency order.

Eh, well, there *are* dependency loops which break this. But in this
specific case, we can be pretty sure that perl-modules will never depend
on bonsai :) [Apart from that, configuration isn't even needed for most
uses]

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
198: kompatibel
   Eine transitive Relation (Gert Doering)


pgpjCYJlkFrEx.pgp
Description: PGP signature

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

2006-12-04 Thread Russ Allbery 
Roberto C Sanchez <[EMAIL PROTECTED]> writes:

> You mean so that different people can file the same bug over and over
> again?  Personally, I'd like to see a notabug tag so that you can have a
> bug still appear on the BTS page but not count (maybe even put the
> notabug bugs at the top or after the RC bugs).  Then people will see
> them and you can have some sort of explanation attached so that people
> can see why the maintainer does not consider it a bug.

That's basically how wontfix is already being used.  Maybe the definition
of wontfix just requires some tweaking.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Mass closing of bugs ?

2006-12-04 Thread Russ Allbery 
Mikhail Gusarov <[EMAIL PROTECTED]> writes:
> You ([EMAIL PROTECTED]) wrote:

>  MH> Considering that the maintainer scripts have not been inherited
>  MH> from mozilla, and that the mozilla engine is pretty different,
>  MH> may I just close all the bugs assigned to old mozilla packages,
>  MH> requesting a reopen if the bug still exists in iceape ?

> Looks like CADT: http://www.jwz.org/doc/cadt.html

Yeah, it is, but, well, there's a good reason why people do that.  jwz is
mostly complaining about the software being repeatedly rewritten and only
secondarily about the resulting mass-closing of bug reports.  Once the
software is rewritten, it really is quite hard to revalidate a lot of
bugs; the real solution is to slowly evolve software rather than rewrite
it completely.

Anyway, the problem we have in Debian is that the rewrite happened
upstream of us and wasn't our choice but we now have to deal with our
resulting backlog of bugs.  My guess is that leaving the bugs open is
actually going to be of less service to the users than a mass-close after
prompting them to recheck the bugs, since the chances of anyone going
through them is rather slim.

However, one way to prevent a simple mass-close of the bugs would be to
volunteer to triage them all!  If someone feels strongly that they deserve
attention and wants to go through and recheck them, I bet the Iceweasel
maintainers wouldn't complain.  :)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bonsai: Candidate for removal from the archive?

2006-12-04 Thread Stephen Gran 
This one time, at band camp, Steve Langasek said:
> On Mon, Dec 04, 2006 at 02:45:26AM +, Stephen Gran wrote:
> > You need Pre-Depends only when a package must be configured before your
> > postinst is run.  In the case of a perl module, I would think it only
> > needs to be unpacked.
> 
> No, you need a Pre-Depends only when a package must be configured before
> your *preinst* is run.  Packages are always configured in dependency order.

Right you are, of course.  It doesn't actually make any difference to
the point at hand, but thanks for the reminder.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Tempfile best practice vs. man pages

2006-12-04 Thread Michael Banck 
On Sun, Dec 03, 2006 at 03:49:27PM -0800, Russ Allbery wrote:
> The warning on mkstemp is wrong, or at least questionable.  

The info manual doesn't have this warning AFAICT.


Michael


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

than one meaning If

2006-12-04 Thread location 

99885


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

here

2006-12-04 Thread capital 

71798


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

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

2006-12-04 Thread Don Armstrong 
On Mon, 04 Dec 2006, Marc Haber wrote:
> On Mon, 4 Dec 2006 00:30:40 -0800, Don Armstrong <[EMAIL PROTECTED]> wrote:
> >On Mon, 04 Dec 2006, Marc Haber wrote:
> >Blocking has been documented for quite some time:
> >
> >revision 1.54
> >date: 2006-07-13 15:14:12 -0700;  author: joeyh;  state: Exp;  lines: +7 -0
> >document block/unblock
> 
> The important information (which file was modified) is missing here.

Heh. I thought that much was obvious; clearly I've been looking at
debbugs for too long.

$ GET http://www.debian.org/Bugs/server-control|grep block
block bugnumber by bug ...
  Note that the fix for the first bug is blocked by the other listed bugs.
unblock bugnumber by bug ...
  Note that the fix for the first bug is no longer blocked by the other

[It's a control command, so it's documented in server-control.wml]
 

Don Armstrong

-- 
I leave the show floor, but not before a pack of caffeinated Jolt gum
is thrust at me by a hyperactive girl screaming, "Chew more! Do more!"
The American will to consume more and produce more personified in a
stick of gum. I grab it.
 -- Chad Dickerson

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


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

Bug#81118: software released GNU General

2006-12-04 Thread must say 

4067



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

Bug#279983: OrderTo an exact

2006-12-04 Thread very common 

33872



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

Bug#148993: Gateway platforms designed

2006-12-04 Thread amp Events 

12971



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

Bug#140230: Migration Did NewsLinks

2006-12-04 Thread foundone 

41614



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