Work-needing packages report for Oct 20, 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: 333 (new: 16)
Total number of packages offered up for adoption: 106 (new: 3)
Total number of packages requested help for: 34 (new: 0)

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



The following packages have been orphaned:

   gs-afpl (#393923), orphaned yesterday (non-free)
 Description: The AFPL Ghostscript PostScript interpreter
 Reverse Depends: courier-faxmail gs-aladdin gs-cjk-resource hpijs
   ijsgutenprint logidee-tools preview-latex raster3d scribus
   scribus-ng
 Installations reported by Popcon: 365

   honyaku-el (#392901), orphaned 6 days ago
 Description: Honyaku-damashii client for emacsen
 Installations reported by Popcon: 3

   kid3 (#393170), orphaned 4 days ago
 Description: KDE MP3 ID3 tag editor
 Installations reported by Popcon: 324

   kompose (#393035), orphaned 5 days ago
 Description: full screen task manager for KDE
 Installations reported by Popcon: 289

   ksimus (#393290), orphaned 4 days ago
 Description: KDE tool for simulating electrical circuits
 Reverse Depends: ksimus-boolean ksimus-datarecorder ksimus-dev
   ksimus-floatingpoint
 Installations reported by Popcon: 383

   ksimus-boolean (#393291), orphaned 4 days ago
 Description: KSimus boolean package
 Installations reported by Popcon: 348

   ksimus-datarecorder (#393292), orphaned 4 days ago
 Description: KSimus datarecorder package
 Installations reported by Popcon: 344

   kwave (#393172), orphaned 4 days ago
 Description: sound editor for KDE
 Installations reported by Popcon: 478

   libctl (#393104), orphaned 5 days ago
 Description: Library for flexible control files
 Reverse Depends: libctl-dev mpb mpb-mpi
 Installations reported by Popcon: 17

   lineak-defaultplugin (#393175), orphaned 4 days ago
 Description: LinEAK default plugin
 Installations reported by Popcon: 182

   lineak-kdeplugins (#393177), orphaned 4 days ago
 Description: LinEAK KDE plugins
 Installations reported by Popcon: 169

   lineak-xosdplugin (#393178), orphaned 4 days ago
 Description: LinEAK On-Screen Display plugin
 Installations reported by Popcon: 177

   lineakd (#393174), orphaned 4 days ago
 Description: Linux support for Easy Access and Internet Keyboards
 Reverse Depends: klineakconfig liblineak-dev lineak-defaultplugin
   lineak-kdeplugins lineak-xosdplugin lineakd
 Installations reported by Popcon: 304

   mpb (#393107), orphaned 5 days ago
 Description: MIT Photonic-Bands
 Reverse Depends: mpb-mpi
 Installations reported by Popcon: 15

   tex-guy (#393925), orphaned yesterday
 Description: miscellaneous utilities using DVIlib
 Reverse Depends: dvilib2-dev spawg spawx11 tex-guy xgdvi
 Installations reported by Popcon: 147

   vflib3 (#393580), orphaned 3 days ago
 Description: a font rasterizer library for multi-lingual information
 Reverse Depends: asiya24-vfont dvilib2 vflib3-bin vflib3-dev
 Installations reported by Popcon: 227

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

   ethstatus (#394092), offered today
 Description: Console-based ethernet statistics monitor
 Installations reported by Popcon: 283

   prestimel (#393256), offered 4 days ago
 Description: tool to create presentations from an XML-file
 Installations reported by Popcon: 13

   xbvl (#393259), offered 4 days ago
 Description: A Lisp implementation developed at Paris 8 University
 Installations reported by Popcon: 15

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

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

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

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

   cvs (#354176), requested 238 days ago
 Descr

Re: gcc-4.2 build-depends?

[Frank Küster]

[EMAIL PROTECTED] wrote:

> Hello,
>
> Frank Küster napsal:
>> "Jiri Palecek" <[EMAIL PROTECTED]> wrote:
>>
>> > Hello,
>> >
>> > can anyone explain why gcc-4.2 build-depends on libgconf2-dev,
>> > libxul-dev,  libart-2.0-dev, libgtk2.0-dev,
>> > lib32asound2-dev, libcairo2-dev, libqt4-dev and several others? It
>> > seems  quite strange (well, even
>> > more) to me.
>>
>> Well, it builds a couple of binary packages that might well need such
>> libraries.  Without looking at the source, names like
>>
>> gappletviewer-4.2 Standalone application to execute Java (tm) applets
>> gcjwebplugin-4.2  Web browser plugin to execute Java (tm) applets
>>
>> sound like good candidates.
>
> I don't think this is, er... wise. This means if I want to make a
> (cross-)compiler, I have to install Qt, GNOME, XUL (which
> conflicts: mozilla-browser) even if I'll never want to use java.

No, you haven't.  The Build-Depends of a Debian package are not meant to
be used for bootstrapping.  You could just disable the respective
stanzas in the control file, build your cross-compiler or compiler for a
new architecture, and once you managed to build Qt and Gnome, you can
enable them again.

> Also, any RC-bug in these will make gcc not suitable for
> testing. I think the same arguments as in Bug#360881 apply
> here. Also, the same solution should be used (eg. split the
> package).

This, however, is a strong argument.

Regards, Frank

-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Bug mass filling

[Tshepang Lekhonkhobe]

On 10/19/06, Mike Hommey <[EMAIL PROTECTED]> wrote:

Waw, actually, i was trying to be less aggressive...

Anyways, since I'm too pissed and since I see no reason to put myself in
that mood any further, I'm taking a few days off Debian, which means my
current work on seamonkey^Hiceape will be on hold. All the work in
progress on my currently maintained packages will be on hold too.

If you want iceape in shape for etch if we are anything near a freeze,
well, get your fingers out of your asses, as we say in french.


I would take it out if it was in there, but please don't be pissed off
so soon. Continue hacking away and let's have the best release ever
:-) I really want to see Seamonkey in Etch, and you even asked the
RM's to allow you to upload it (version 1.1) when released later this
month.


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

Horiny playboy teenie pak

[Alexis Negron]

access news: Hot XXX Fuckoing!!! Thebse girls lopve a nice stbiff coyck!! :)
GOTO: *** plbrl.zopurar.com ***

their capo look really eyes provide soon, after here can, form twice link all 
form?
loose eyes surf add today out forever order; self and, just other they.
face online are told,  access eyes?


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

Re: How can the OS autodetect that a user is a newbie and offer help?

[Andrew Vaughan]

On Friday 20 October 2006 08:06, Peter Samuelson wrote:
> [Sander Marechal]
>
> > True, but I meant that an app can kill X, requiring it to be restarted.
> > Newbies get very confused at that point.
>
> Look, if you typed "startx" once, you can type it again.
>
> If you didn't, it means you're using a display manager like xdm, and
> xdm will restart X when it dies.
>
> If X just _freezes_ rather than dies, you don't get a shell prompt
> anyway.  What you get is the opportunity to hit Ctrl-Alt-Backspace, so
> that X will die, and then you're back to the previous cases.
>
> I see no case where it is useful to alias "startx" to "start-desktop".
I agree.

> Unless X dies and then xdm _also_ dies.  Does this ever happen?
Even if it does, that should be recoverable by, at worst, power cycling the 
machine.  

The real problem is when someone who has never used the command line before, 
possibly never even seen the command line, is stranded in a vt because X 
didn't start during boot, started and immediately crashed, or crashes every 
time they login.  

They don't know how to do anything from the command-line.  They don't even 
know how to read a man page/edit a file.  They're the users who need basic 
cli help. 

A motd message saying type `help-me' for help, and a 3-4 page doc explaining 
some useful basic commands (man, less, nano, cd, cp, rm, startx etc) and 
how to reconfigure X might be enough to prevent some of them having to 
re-install.  

Just my 2 cents
Andrew



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

Re: how can download and run checklib

[gregor herrmann]

On Fri, 20 Oct 2006 08:47:48 +1000, Aníbal Monsalve Salazar wrote:

> I also couldn't find in the FAQ [3] any reference about how to
> download checklib.
> [3] http://rerun.lefant.net/checklib/faq.html 
> How can download and run checklib?

On http://rerun.lefant.net/checklib/ the last line says:
"Source code: available here" (and 'available here' is a link leading
to http://greek0.net/div/checklib.tar.gz ).

gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Frank Sinatra: I Get A Kick Out Of You


signature.asc
Description: Digital signature

how can download and run checklib

[Aníbal Monsalve Salazar]

Hello,

There is a link to Checklib [0] in the Packages Overview page
of every maintainer. See for example vorlon's page at [1] where
you could see that link in the line starting with "Reports:".

[0] http://rerun.lefant.net/checklib/
[1] http://qa.debian.org/developer.php?login=vorlon

I couldn't find checklib in packages.debian.org [2].

[2]
http://packages.debian.org/cgi-bin/search_contents.pl?word=checklib&searchmode=searchfiles&case=insensitive&version=unstable&arch=i386

I also couldn't find in the FAQ [3] any reference about how to
download checklib.

[3] http://rerun.lefant.net/checklib/faq.html 

How can download and run checklib?

Mit freundlichen Grüßen,

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: Bug mass filling

[Don Armstrong]

On Thu, 19 Oct 2006, Kevin Mark wrote:
> DD's trying to use Debian policy as a guide to make all packages
> pass policy requirement. Is this not what they are tasked to do?

There's nothing wrong with these goals. Indeed, I'm sure no one would
object to patches and bugs being filed to fix these policy issues.

The only question is whether the bugs are RC or not. The RMs have the
ability to determine which policy issues are RC; the people who can
override their decision (by making other bugs RC) are the maintainers
for a particular package, by deciding that a particular package is not
fit for release.

Otherwise, when the RMs have clarified the release policy (as they
have just done), then we should go back to fixing bugs instead of
arguing about whether or not the bugs are really all that bad or not.


Don Armstrong

-- 
Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
 -- Antoine de Saint-Exupe'ry, Terres des Hommes

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


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

Re: How can the OS autodetect that a user is a newbie and offer help?

[Peter Samuelson]

[Sander Marechal]
> True, but I meant that an app can kill X, requiring it to be restarted.
> Newbies get very confused at that point.

Look, if you typed "startx" once, you can type it again.

If you didn't, it means you're using a display manager like xdm, and
xdm will restart X when it dies.

If X just _freezes_ rather than dies, you don't get a shell prompt
anyway.  What you get is the opportunity to hit Ctrl-Alt-Backspace, so
that X will die, and then you're back to the previous cases.

I see no case where it is useful to alias "startx" to "start-desktop".
Unless X dies and then xdm _also_ dies.  Does this ever happen?


signature.asc
Description: Digital signature

Re: Bug mass filling

[Steve Langasek]

On Thu, Oct 19, 2006 at 10:52:25PM +0200, Mike Hommey wrote:
> On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
> > * Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
> > > [another agression]

> Waw, actually, i was trying to be less aggressive...

This is a very, very old argument, and it doesn't really come across to me
as less aggressive to continue to suggest that the RMs are "changing the
rules" to meet the release deadline, or even that it will *appear* that we
are doing so, when these are rules that have governed the use of RC
severities in the BTS for at least the past three years and are explicitly
sanctioned by the BTS admins.

So I'm sorry that this upsets you, but it's not exactly the release team's
fault if people are inferring things from the BTS documentation that aren't
written there.

-- 
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: Bug mass filling

[Kevin Mark]

On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
> > [another agression]
> 
> Sorry, but enough is enough. I'm fed up about your sudden agressions
> towards me for no reason at all. Welcome to my killfile.
> 
> 
Hi Andi,
from my perspective, I see this:
DD's trying to use Debian policy as a guide to make all packages pass
policy requirement. Is this not what they are tasked to do ? They see
inconsistencies between RM's understanding of these and their goals. And
they seem to say that if someone would alter, fix, change or clarify
policy, they could have a clear goal for them to reach release targets.
This way they would not be confused about the unclear judgments that
they are reading from RM's and won't bother them for further questions
that waste everyones time and patience. I dont see this as an attack on
RM's, I see it as folks wanting help to reach release goals and want
someone to just clarify policy. Now if nobody clarifies policy, they
have to get guidance from the only people who can: RM's. If there is
some reason why the RM's are not able/willing to do this, then that
leads to only further frustration and no progress, as witnesses by this
and other threads. So, if someone can just update, clarify, fix, or in
someway address this, please lets focus on the real goal: liw's tattoo!
have a nice day!
cheers,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
> > [another agression]

Waw, actually, i was trying to be less aggressive...

Anyways, since I'm too pissed and since I see no reason to put myself in
that mood any further, I'm taking a few days off Debian, which means my
current work on seamonkey^Hiceape will be on hold. All the work in
progress on my currently maintained packages will be on hold too.

If you want iceape in shape for etch if we are anything near a freeze,
well, get your fingers out of your asses, as we say in french.

Mike


signature.asc
Description: Digital signature

Re: Bug mass filling

[Julien BLACHE]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> Be aware that, even if you don't like it, this looks like you bend the
> rules so that it doesn't alter the release plan.
> Be also aware that too much bending the rules makes them useless.

Don't try to bend the rules, it's impossible. Instead, only realize
the truth: there are no rules.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Re: Bug mass filling

[Thomas Bushnell BSG]

Mike Hommey <[EMAIL PROTECTED]> writes:

>> So, what does the Etch RC policy remove from the bugs.d.o description?
>
> 'is a severe violation of Debian policy (roughly, it violates a "must" or
>  "required" directive), or'

Perhaps you should concentrate on the word "roughly" there.  What
constitutes a severe violation is in the judgment of the Release Team,
and the release goals indicate their judgment in the context of a
particular release.

Thomas


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

Re: ethstatus: no upstream, RFA or removal?

[Christoph Haas]

On Thursday 19 October 2006 13:37, Christoph Haas wrote:
> I'm the maintainer of the "ethstatus" package - a console-based ethernet
> statistics monitor. You can e.g. run it on your gateway's 9" CRT on the
> console and see how much bandwidth is currently used in a bar-like view.
> I'm in the process of RFA'ing the package. But I wonder whether I should
> even request for this package to get removed.

Case closed. Aurélien GÉRÔME just adopted the package. Thanks.

 Christoph
-- 
Famous coworker quote: "I'm still confused - just on a higher level now."

Re: Bug mass filling

[Frank Küster]

Mike Hommey <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 19, 2006 at 10:20:46PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
>> * Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]:
>> > Where does it say the scope for 4. Autobuilding is "buildds must not
>> > fail" ?
>> 
>> There are always bugs in any document.
>
> Be aware that, even if you don't like it, this looks like you bend the
> rules so that it doesn't alter the release plan.
> Be also aware that too much bending the rules makes them useless.

What about your proposing a GR to recall the Release Managers?  

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
> [another agression]

Sorry, but enough is enough. I'm fed up about your sudden agressions
towards me for no reason at all. Welcome to my killfile.


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


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

Re: gcc-4.2 build-depends?

[jpalecek]

Hello,

Frank Küster napsal:
> "Jiri Palecek" <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > can anyone explain why gcc-4.2 build-depends on libgconf2-dev,
> > libxul-dev,  libart-2.0-dev, libgtk2.0-dev,
> > lib32asound2-dev, libcairo2-dev, libqt4-dev and several others? It
> > seems  quite strange (well, even
> > more) to me.
>
> Well, it builds a couple of binary packages that might well need such
> libraries.  Without looking at the source, names like
>
> gappletviewer-4.2 Standalone application to execute Java (tm) applets
> gcjwebplugin-4.2  Web browser plugin to execute Java (tm) applets
>
> sound like good candidates.

I don't think this is, er... wise. This means if I want to make a
(cross-)compiler, I have to install Qt, GNOME, XUL (which
conflicts: mozilla-browser) even if I'll never want to use java.
Also, any RC-bug in these will make gcc not suitable for
testing. I think the same arguments as in Bug#360881 apply
here. Also, the same solution should be used (eg. split the
package).

Regards
Jiri Palecek

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 10:20:46PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]:
> > Where does it say the scope for 4. Autobuilding is "buildds must not
> > fail" ?
> 
> There are always bugs in any document.

Be aware that, even if you don't like it, this looks like you bend the
rules so that it doesn't alter the release plan.
Be also aware that too much bending the rules makes them useless.


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

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 10:15:16PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 22:06]:
> > That was not a link before it was changed before sarge release, in July
> > 2004.
> 
> The link was added later because people were barking around. The meaning
> was always the same.

The meaning of "Debian Policy" was always something else than
http://www.us.debian.org/doc/debian-policy/ ? Come on...

Mike


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

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]:
> Where does it say the scope for 4. Autobuilding is "buildds must not
> fail" ?

There are always bugs in any document.

For sarge, we e.g. sarge-ignored some MTAs which didn't provide -bs,
though LSB requires that. Now, we adjusted the policy to make it legal
(as long as they conflict with lsb of course). Nothing wrong with that,
the text isn't written in stone.


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


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

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 22:06]:
> That was not a link before it was changed before sarge release, in July
> 2004.

The link was added later because people were barking around. The meaning
was always the same.

Anyways, July 2004 is a *bit* history now, don't you think so?

> So, what is written on http://www.debian.org/Bugs/Developer#severities
> doesn't count (not to say it's crap), and it's not necessary to change
> it.

If you disagree with what is written on the page, you might want to ask
[EMAIL PROTECTED] for clarification, or you could appeal to the
Technical Committee, or you could ask the developers in a GR. Until you
succeed at at least one of the ways, the definition as written down by a
member of [EMAIL PROTECTED] stays valid. As it is always.


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


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

Is there a need for /usr/lib64/ on a pure i386?

[Stanislav Maslovski]

Hello d-dev,

I noticed yesterday that after an upgrade I got a /usr/lib64 dir
with some (not neded) stuff in it. I am not running any 64 bit arch.

$ dpkg -S /usr/lib64 # says:
libg2c0-dev, fakeroot, libgfortran1-dev: /usr/lib64

I have found that there is a bug [1] on fakeroot reporting the same.

The question is: will it become a common practice that packages for i386
will include 64-bit libraries? After reading the reply of Clint Adams on [1]
I have got such an impression. Please correct me if I am wrong.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344104

-- 
Станислав

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 09:56:37PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Aurelien Jarno ([EMAIL PROTECTED]) [061019 21:31]:
> > Andreas Barth a écrit :
> > >A violation of the parts of the debian policy as listed on
> > >http://release.debian.org/etch_rc_policy.txt is serious level (that
> > >should be the same as the must-directives in policy, but - well, I hope
> > >that I have finally time post-etch to sync that finally).
> > >
> > >Any other policy violation is at most important level (unless it
> > >conincides with one of the other criteria for RC bugs, of course).
> > >
> > 
> > Note that what we are discussing (must have in targets debian/rules) are 
> > listed on http://release.debian.org/etch_rc_policy.txt
> 
> As vorlon said, that is listed under the heading of "4. Autobuilding",
> so the scope is "buildds must not fail" of this rule. That is why I

Where does it say the scope for 4. Autobuilding is "buildds must not
fail" ?

It does say "Packages must autobuild without failure on all
architectures on which they are supported", but that's one of the
options that make a bug RC.


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

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 03:53:56PM -0400, Eric Dorland <[EMAIL PROTECTED]> 
wrote:
> * Andreas Barth ([EMAIL PROTECTED]) wrote:
> > * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
> > > On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL 
> > > PROTECTED]> wrote:
> > > > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > > > > Note how subtly the Etch RC policy removes the first alternative of 
> > > > > the
> > > > > serious bug description...
> > > > 
> > > > Which do you mean? Please read the Etch RC policy. It tells:
> > > > | In addition to the issues listed in this document, an issue is release
> > > > | critical if it:
> > > > | [...]
> > > > | * in the maintainer's opinion, makes the package unsuitable
> > > > | for release
> > > > 
> > > > So, what does the Etch RC policy remove from the bugs.d.o description?
> > > 
> > > 'is a severe violation of Debian policy (roughly, it violates a "must" or
> > >  "required" directive), or'
> > 
> > The html-code for this part is:
> > serious
> > is a http://release.debian.org/etch_rc_policy.txt";>severe
> > violation of Debian policy (roughly, it violates a "must" or "required"
> > directive), or, in the package maintainer's opinion, makes the package
> > unsuitable for release.
> > 
> > So, obviously http://www.debian.org/Bugs/Developer#severities defines
> > that "severe violation of Debian policy" means anything referenced in
> > the etch_rc_policy-document.
> 
> I would have thought that meant a violation of
> http://www.us.debian.org/doc/debian-policy/.

That was not a link before it was changed before sarge release, in July
2004.

Interesting log in the web page cvs:

  The RM defines what the 'serious' severity means.

   regarding -a and -o in -test, aj, Kamion and vorlon said on June 8
that it is not considered RC by you guys. Okay to tag bugs with
'... uses XSIisms (test ... -a/-o ...) with sarge-ignore?
   jvw: no, it's not okay for them to be marked RC in the first place
   http://people.debian.org/~ajt/sarge_rc_policy.txt is the canonical
   place to look for the definition of "severe policy violation"
   sarge-ignore is not possible as it is not an RC issue
  [...]
   aj: so you say http://www.debian.org/Bugs/Developer#severities is
wrong?
   whatever
   I'm not going to be able to convince people that
http://www.debian.org/Bugs/Developer#severities is wrong, but I
might be able to say it isn't a Sarge issue at least, but that
involves sarge-ignore, which requires your okay
   it doesn't matter what that page says
   http://people.debian.org/~ajt/sarge_rc_policy.txt is canonical
   if the bug doesn't match the criteria on that page it's not serious
   grave or critical

So, what is written on http://www.debian.org/Bugs/Developer#severities
doesn't count (not to say it's crap), and it's not necessary to change
it.

By the way, reportbug doesn't give anything close to a hint that it
could be anything else than than Debian Policy:

3 serious
  is a severe violation of Debian policy (that is, the problem is a
  violation of a 'must' or 'required' directive); may or may not affect
  the usability of the package. Note that non-severe policy violations
  may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers
  may also designate other bugs as 'serious' and thus release-critical;
  however, end users should not do so.)


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

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 09:35:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> But I need to admit that I get sick, seriously sick. If someone doesn't
> agree with something, he just says "you do it wrong just for release of
> etch on $date". I really hate that. Especially when it's about things
> that are done that way since ages, but someone just recently has become
> aware of that.

I need to admit that I get sick, seriously sick of all that has been happening
in Debian in the last couple of months, between RM funding, dunc-tank, people
resigning, release date chosen on odd grounds, do whatever to release on that
date, whatever, 42 stupid useless GRs to delay (again) what was delayed
in order to release sarge, Sven Luther vs. Sven Luther's enemies, ...
... ... ...
I'm not even talking about that stupid Mozilla® affair.

> That really takes the fun away from Debian for me.

Same here.

Mike


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

Re: Bug mass filling

[Andreas Barth]

* Aurelien Jarno ([EMAIL PROTECTED]) [061019 21:31]:
> Andreas Barth a écrit :
> >A violation of the parts of the debian policy as listed on
> >http://release.debian.org/etch_rc_policy.txt is serious level (that
> >should be the same as the must-directives in policy, but - well, I hope
> >that I have finally time post-etch to sync that finally).
> >
> >Any other policy violation is at most important level (unless it
> >conincides with one of the other criteria for RC bugs, of course).
> >
> 
> Note that what we are discussing (must have in targets debian/rules) are 
> listed on http://release.debian.org/etch_rc_policy.txt

As vorlon said, that is listed under the heading of "4. Autobuilding",
so the scope is "buildds must not fail" of this rule. That is why I
asked to file the cases where buildds failed as serious, and the others
as important (and cases where "Packages in the archive must not be so
buggy [...] we refuse to support them." as serious as well, that is
under section "5. General").



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


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

Re: Bug mass filling

[Eric Dorland]

* Andreas Barth ([EMAIL PROTECTED]) wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
> > On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> > wrote:
> > > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > > > Note how subtly the Etch RC policy removes the first alternative of the
> > > > serious bug description...
> > > 
> > > Which do you mean? Please read the Etch RC policy. It tells:
> > > | In addition to the issues listed in this document, an issue is release
> > > | critical if it:
> > > | [...]
> > > | * in the maintainer's opinion, makes the package unsuitable
> > > | for release
> > > 
> > > So, what does the Etch RC policy remove from the bugs.d.o description?
> > 
> > 'is a severe violation of Debian policy (roughly, it violates a "must" or
> >  "required" directive), or'
> 
> The html-code for this part is:
> serious
> is a http://release.debian.org/etch_rc_policy.txt";>severe
> violation of Debian policy (roughly, it violates a "must" or "required"
> directive), or, in the package maintainer's opinion, makes the package
> unsuitable for release.
> 
> So, obviously http://www.debian.org/Bugs/Developer#severities defines
> that "severe violation of Debian policy" means anything referenced in
> the etch_rc_policy-document.

I would have thought that meant a violation of
http://www.us.debian.org/doc/debian-policy/. I certainly think it's
the release manager's responsibility to mark bugs that are not release
blocking etch-ignore, but if it is a violation of policy it should
still be serious. 

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



signature.asc
Description: Digital signature

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 21:25]:
> On Thu, Oct 19, 2006 at 09:17:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
> > * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
> > > On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL 
> > > PROTECTED]> wrote:
> > > > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > > > > Note how subtly the Etch RC policy removes the first alternative of 
> > > > > the
> > > > > serious bug description...
> > > > 
> > > > Which do you mean? Please read the Etch RC policy. It tells:
> > > > | In addition to the issues listed in this document, an issue is release
> > > > | critical if it:
> > > > | [...]
> > > > | * in the maintainer's opinion, makes the package unsuitable
> > > > | for release
> > > > 
> > > > So, what does the Etch RC policy remove from the bugs.d.o description?
> > > 
> > > 'is a severe violation of Debian policy (roughly, it violates a "must" or
> > >  "required" directive), or'
> > 
> > The html-code for this part is:
> > serious
> > is a http://release.debian.org/etch_rc_policy.txt";>severe
> > violation of Debian policy (roughly, it violates a "must" or "required"
> > directive), or, in the package maintainer's opinion, makes the package
> > unsuitable for release.
> > 
> > So, obviously http://www.debian.org/Bugs/Developer#severities defines
> > that "severe violation of Debian policy" means anything referenced in
> > the etch_rc_policy-document.
> 
> Yeah, right, whatever, as soon as etch is release on December 4th...

What do you intend to say by that? The definition of serious was already
that way when I was looking at the release from the very outside, before
I was a DD even (ok, it was sarge_rc_policy.txt, and not etch at that
time). It has *nothing* whatsoever to do with the planned release date
...


But I need to admit that I get sick, seriously sick. If someone doesn't
agree with something, he just says "you do it wrong just for release of
etch on $date". I really hate that. Especially when it's about things
that are done that way since ages, but someone just recently has become
aware of that.

That really takes the fun away from Debian for me. I don't know if
that's what you intend, but that's what you achieve.


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


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

Re: Bug mass filling

[Aurelien Jarno]

Andreas Barth a écrit :

A violation of the parts of the debian policy as listed on
http://release.debian.org/etch_rc_policy.txt is serious level (that
should be the same as the must-directives in policy, but - well, I hope
that I have finally time post-etch to sync that finally).

Any other policy violation is at most important level (unless it
conincides with one of the other criteria for RC bugs, of course).



Note that what we are discussing (must have in targets debian/rules) are 
listed on http://release.debian.org/etch_rc_policy.txt



--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 09:17:38PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
> > On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> > wrote:
> > > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > > > Note how subtly the Etch RC policy removes the first alternative of the
> > > > serious bug description...
> > > 
> > > Which do you mean? Please read the Etch RC policy. It tells:
> > > | In addition to the issues listed in this document, an issue is release
> > > | critical if it:
> > > | [...]
> > > | * in the maintainer's opinion, makes the package unsuitable
> > > | for release
> > > 
> > > So, what does the Etch RC policy remove from the bugs.d.o description?
> > 
> > 'is a severe violation of Debian policy (roughly, it violates a "must" or
> >  "required" directive), or'
> 
> The html-code for this part is:
> serious
> is a http://release.debian.org/etch_rc_policy.txt";>severe
> violation of Debian policy (roughly, it violates a "must" or "required"
> directive), or, in the package maintainer's opinion, makes the package
> unsuitable for release.
> 
> So, obviously http://www.debian.org/Bugs/Developer#severities defines
> that "severe violation of Debian policy" means anything referenced in
> the etch_rc_policy-document.

Yeah, right, whatever, as soon as etch is release on December 4th...


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

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
> On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
> > * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > > Note how subtly the Etch RC policy removes the first alternative of the
> > > serious bug description...
> > 
> > Which do you mean? Please read the Etch RC policy. It tells:
> > | In addition to the issues listed in this document, an issue is release
> > | critical if it:
> > | [...]
> > | * in the maintainer's opinion, makes the package unsuitable
> > | for release
> > 
> > So, what does the Etch RC policy remove from the bugs.d.o description?
> 
> 'is a severe violation of Debian policy (roughly, it violates a "must" or
>  "required" directive), or'

The html-code for this part is:
serious
is a http://release.debian.org/etch_rc_policy.txt";>severe
violation of Debian policy (roughly, it violates a "must" or "required"
directive), or, in the package maintainer's opinion, makes the package
unsuitable for release.

So, obviously http://www.debian.org/Bugs/Developer#severities defines
that "severe violation of Debian policy" means anything referenced in
the etch_rc_policy-document.


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


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

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> > Note how subtly the Etch RC policy removes the first alternative of the
> > serious bug description...
> 
> Which do you mean? Please read the Etch RC policy. It tells:
> | In addition to the issues listed in this document, an issue is release
> | critical if it:
> | [...]
> | * in the maintainer's opinion, makes the package unsuitable
> | for release
> 
> So, what does the Etch RC policy remove from the bugs.d.o description?

'is a severe violation of Debian policy (roughly, it violates a "must" or
 "required" directive), or'

> > Anyways, I've always thought the bts severity levels and release
> > criticality were orthogonal things. i.e. it's more complicated than
> > just saying "critical, grave and serious levels are RC".
> 
> That is wrong.
> 
> > There are
> > important or even normal issues (as per definition of the severity
> > levels) that are more release critical than serious (again, as per
> > definition of the severity levels) bugs.
> 
> Wrong. A bug is release-critical :<=> the bug has severity serious,
> grave, critical and has not been given an excemption by the release team

You may have missed the "thought" part of the sentence.

Mike


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

Re: Bug mass filling

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
> Note how subtly the Etch RC policy removes the first alternative of the
> serious bug description...

Which do you mean? Please read the Etch RC policy. It tells:
| In addition to the issues listed in this document, an issue is release
| critical if it:
| [...]
| * in the maintainer's opinion, makes the package unsuitable
| for release

So, what does the Etch RC policy remove from the bugs.d.o description?

> Anyways, I've always thought the bts severity levels and release
> criticality were orthogonal things. i.e. it's more complicated than
> just saying "critical, grave and serious levels are RC".

That is wrong.

> There are
> important or even normal issues (as per definition of the severity
> levels) that are more release critical than serious (again, as per
> definition of the severity levels) bugs.

Wrong. A bug is release-critical :<=> the bug has severity serious,
grave, critical and has not been given an excemption by the release team

> But yet, violation of the Debian policy should be granted serious level.
> etch-ignore is here to make the issue not release critical.

Wrong. Etch-ignore is for exemptions for issues that otherwise match the
definition of release critical on that page. It is not for "normal
sorting" of issues.


A violation of the parts of the debian policy as listed on
http://release.debian.org/etch_rc_policy.txt is serious level (that
should be the same as the must-directives in policy, but - well, I hope
that I have finally time post-etch to sync that finally).

Any other policy violation is at most important level (unless it
conincides with one of the other criteria for RC bugs, of course).


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


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

Re: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 11:29:38AM -0700, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> On Thu, Oct 19, 2006 at 07:51:19PM +0200, Mike Hommey wrote:
> > On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> > wrote:
> > > > Doesn't policy violation warrant Critical severity?
> 
> > > No. Please see the top of http://release.debian.org/etch_rc_policy.txt
> > > for which bugs are critical, grave and serious.
> 
> > That is irrelevant for the severity of bugs.
> 
> > This is the relevant definition:
> 
> > serious is a severe violation of Debian policy (that is, the
> > problem is a violation of a 'must' or 'required' directive)
> 
> That definition, as listed on
> , links straight to the
> release team's RC bug policy.

Note how subtly the Etch RC policy removes the first alternative of the
serious bug description...

Anyways, I've always thought the bts severity levels and release
criticality were orthogonal things. i.e. it's more complicated than
just saying "critical, grave and serious levels are RC". There are
important or even normal issues (as per definition of the severity
levels) that are more release critical than serious (again, as per
definition of the severity levels) bugs.

But yet, violation of the Debian policy should be granted serious level.
etch-ignore is here to make the issue not release critical.

Mike


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

Re: Bug mass filling

[Steve Langasek]

On Thu, Oct 19, 2006 at 07:51:19PM +0200, Mike Hommey wrote:
> On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
> > > Doesn't policy violation warrant Critical severity?

> > No. Please see the top of http://release.debian.org/etch_rc_policy.txt
> > for which bugs are critical, grave and serious.

> That is irrelevant for the severity of bugs.

> This is the relevant definition:

> serious is a severe violation of Debian policy (that is, the
> problem is a violation of a 'must' or 'required' directive)

That definition, as listed on
, links straight to the
release team's RC bug policy.

-- 
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: Bug mass filling

[Adam D. Barratt]

On Thu, 2006-10-19 at 10:00 -0700, Kevin B. McCarty wrote:
> Tshepang Lekhonkhobe wrote:
> 
> > Doesn't policy violation warrant Critical severity?
> 
> No, it "only" warrants the lowest RC severity, serious [0], unless the
> bug in addition makes the package or other software (mostly) unusable,
> causes data loss, or introduces a security hole.

Even then, it's only "serious" if it violates the release policy
[http://release.debian.org/etch_rc_policy.txt]. Hence the reason that

> [0] http://www.debian.org/Bugs/Developer#severities

says "[...]roughly, it violates a "must" or "required" directive". The
final word for what justifies a release-critical severity belongs to the
release team (hence also the paragraph on rc-ness at the foot of the
documentation).

Adam


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

Re: Bug mass filling

[Adam D. Barratt]

On Thu, 2006-10-19 at 19:51 +0200, Mike Hommey wrote:
> On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
> wrote:
> > > Doesn't policy violation warrant Critical severity?
> > 
> > No. Please see the top of http://release.debian.org/etch_rc_policy.txt
> > for which bugs are critical, grave and serious.
> 
> That is irrelevant for the severity of bugs.
[...]
> Don't change severities for releasing-in-time purposes. There is

Erm... the release team have been the arbiters of what merits an RC
severity since at least before Sarge was released.

>From http://www.debian.org/Bugs/Developer#severities:

"Certain severities are considered release-critical, meaning the bug
will have an impact on releasing the package with the stable release of
Debian. Currently, these are critical, grave and serious. For complete
and canonical rules on what issues merit these severities, see the list
of Release-Critical Issues for Etch." The top of the latter page reads

"The purpose of this document is to be a correct, complete and canonical
list of issues that merit a "serious" bug under the clause "a severe
violation of Debian policy". 

In addition to the issues listed in this document, an issue is release
critical if it:
[...]

* in the maintainer's opinion, makes the package unsuitable
  for release
(these issues are "serious" severity)
"

i.e. if it's not in the policy and doesn't meet the above definition,
it's *not* severity serious or higher.

I'd suggest reading
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277074;msg=72, in which
a current member of [EMAIL PROTECTED] (and at the time an RM) confirms that a
member of the ftp-master team was correct in stating the above.

Adam


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

Re: Bug mass filling

[Steve Langasek]

On Thu, Oct 19, 2006 at 07:01:20PM +0200, Frans Pop wrote:
> On Thursday 19 October 2006 18:45, Petter Reinholdtsen wrote:
> > If no problem is caused by it, I believe 'normal' or even 'wishlist'
> > severity is the proper severity to use.

> s/wishlist/minor/

> It _is_ a bug after all.

s/minor/important/, which is the severity used for policy violations that
don't qualify as release-critical.

And in this case, yes, the bugs should be filed as important rather than
serious; the etch RC policy claims they should be serious, but it also does
this in the section on "autobuilding" -- if no one has found any problems
autobuilding these packages before now, despite multiple full-archive
rebuilds over the past year, then it's a bug in the etch RC policy to
suggest that these should be RC when they don't cause practical problems.

-- 
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: Bug mass filling

[Mike Hommey]

On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> > Doesn't policy violation warrant Critical severity?
> 
> No. Please see the top of http://release.debian.org/etch_rc_policy.txt
> for which bugs are critical, grave and serious.

That is irrelevant for the severity of bugs.

This is the relevant definition:

serious is a severe violation of Debian policy (that is, the
problem is a violation of a 'must' or 'required' directive)

And in our case, the policy says:

Both the binary-arch and binary-indep targets must exist.

Don't change severities for releasing-in-time purposes. There is
etch-ignore for that.

Mike, wondering how many RC bugs will be tagged etch-ignore to reach the
80 bugs before freeze.


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

Re: Bug mass filling

[Andreas Barth]

* Aurelien Jarno ([EMAIL PROTECTED]) [061019 15:06]:
> Among all of the bugs reported by lintian, one concerns a lot of
> packages, the presence of the clean, binary, binary-arch, binary-indep 
> and build targets. This is required by both the section 4.9 of the
> policy and the Etch release standards [1]. Here is the list of affected
> packages. What to do with them?

If the bug also affects our autobuilders (especially the package has
binary-any-packages), serious. Otherwise, important severity.

If a package is totally broken (which might be in this case), serious
might also be ok - but that needs to be decided on a case-by-case-basis.


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


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

Re: Bug mass filling

[Andreas Barth]

* Tshepang Lekhonkhobe ([EMAIL PROTECTED]) [061019 18:09]:
> On 10/19/06, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> >
> >[Aurelien Jarno]
> >> I have just run lintian on all the archive (amd64) for both binaries and
> >> sources, and the results are a bit scary. It looks like a lot of
> >> maintainers are uploading their packages, and don't really care with the
> >> policy.
> >
> >What is the technical problem triggered by the packages with this
> >lintian message?  Is the autobuilders able to build these packages?
> >If the autobuilders fail, I recommend you report that as a important
> >or serious problem, and it it isn't, I recommend you report it as a
> >normal bug.
> 
> Doesn't policy violation warrant Critical severity?

No. Please see the top of http://release.debian.org/etch_rc_policy.txt
for which bugs are critical, grave and serious.



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


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

Re: Bug mass filling

[Julien Danjou]

On Thu, Oct 19, 2006 at 06:45:53PM +0200, Petter Reinholdtsen wrote:
> Well, policy isn't a stick to beat other maintainers with, it is a
> tool to make sure our packages are well integrated and work properly.
> Thus, policy issues are not problems by themselves, they are policy
> issues because they might cause problems.  And in this case, I am not
> sure what the exact problem caused by the lack of the binary-indep
> target is, so I ask.
> 
> If no problem is caused by it, I believe 'normal' or even 'wishlist'
> severity is the proper severity to use.

If there's no problem, change the policy.

-- 
Julien Danjou
.''`.  Debian Developer
: :' : http://julien.danjou.info
`. `'  http://people.debian.org/~acid
  `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD


signature.asc
Description: Digital signature

Re: Bug mass filling

[Frans Pop]

On Thursday 19 October 2006 18:45, Petter Reinholdtsen wrote:
> If no problem is caused by it, I believe 'normal' or even 'wishlist'
> severity is the proper severity to use.

s/wishlist/minor/

It _is_ a bug after all.


pgp8CuxfBlHbn.pgp
Description: PGP signature

Re: Bug mass filling

[Kevin B. McCarty]

Tshepang Lekhonkhobe wrote:

> Doesn't policy violation warrant Critical severity?

No, it "only" warrants the lowest RC severity, serious [0], unless the
bug in addition makes the package or other software (mostly) unusable,
causes data loss, or introduces a security hole.

[0] http://www.debian.org/Bugs/Developer#severities

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


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

Re: Bug mass filling

[Petter Reinholdtsen]

[Tshepang Lekhonkhobe]
> Doesn't policy violation warrant Critical severity?

Well, policy isn't a stick to beat other maintainers with, it is a
tool to make sure our packages are well integrated and work properly.
Thus, policy issues are not problems by themselves, they are policy
issues because they might cause problems.  And in this case, I am not
sure what the exact problem caused by the lack of the binary-indep
target is, so I ask.

If no problem is caused by it, I believe 'normal' or even 'wishlist'
severity is the proper severity to use.


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

Re: Bug mass filling

[Tshepang Lekhonkhobe]

On 10/19/06, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:


[Aurelien Jarno]
> I have just run lintian on all the archive (amd64) for both binaries and
> sources, and the results are a bit scary. It looks like a lot of
> maintainers are uploading their packages, and don't really care with the
> policy.

What is the technical problem triggered by the packages with this
lintian message?  Is the autobuilders able to build these packages?
If the autobuilders fail, I recommend you report that as a important
or serious problem, and it it isn't, I recommend you report it as a
normal bug.


Doesn't policy violation warrant Critical severity?


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

Re: cmake build-depends

[Margarita Manterola]

On 10/19/06, Jean Parpaillon <[EMAIL PROTECTED]> wrote:


As a side effect, can someone tell me if there is a command to search
for packages regarding Build-Depends ?


grep-dctrl -sPackage -F Build-Depends,Build-Depends-Indep cmake
/var/lib/apt/lists/*Sources

Or, see the more elaborate version, by Damián Viano:

http://damianv.com.ar/downloads/rbuildepend


--
Besos,
Marga

Re: Bug mass filling

[Petter Reinholdtsen]

[Aurelien Jarno]
> I have just run lintian on all the archive (amd64) for both binaries and
> sources, and the results are a bit scary. It looks like a lot of 
> maintainers are uploading their packages, and don't really care with the 
> policy.

What is the technical problem triggered by the packages with this
lintian message?  Is the autobuilders able to build these packages?
If the autobuilders fail, I recommend you report that as a important
or serious problem, and it it isn't, I recommend you report it as a
normal bug.

Friendly,
-- 
Petter Reinholdtsen


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

cmake build-depends

[Jean Parpaillon]

Hi all,
I maintain the package wormux and my dear upstream devels decided to 
switch from autotools to cmake, for the best and the worse.
Are there people with experiences with it ? Maybe kde packagers are 
already working on it ?


As a side effect, can someone tell me if there is a command to search 
for packages regarding Build-Depends ?


Best regards,
Jean

--
_
/ La théorie est absurde dans la \
| pratique et la pratique est aveugle |
\ sans la théorie. -+- Emmanuel Kant -+- /
-
   \   ^__^
\  (--)\___
   (__)\   )\/\
   ||w |
   || ||


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

Re: ethstatus: no upstream, RFA or removal?

[Matthias Julius]

Christoph Haas <[EMAIL PROTECTED]> writes:

> I'm unhappy with the missing upstream situation. I could also wait for a 
> volunteer to maintain both the software and the maintainer.
      ^^

What kind of maintenance do *you* need?

Matthias


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

Bug mass filling

[Aurelien Jarno]

Hi all,

I have just run lintian on all the archive (amd64) for both binaries and
sources, and the results are a bit scary. It looks like a lot of 
maintainers are uploading their packages, and don't really care with the 
policy.

Maybe some errors (E:) of lintian could be changed to critical (C:) and
uploads containing such critical errors be refused by dak? What do you
think?


Among all of the bugs reported by lintian, one concerns a lot of
packages, the presence of the clean, binary, binary-arch, binary-indep 
and build targets. This is required by both the section 4.9 of the
policy and the Etch release standards [1]. Here is the list of affected
packages. What to do with them?

E: adeos source: debian-rules-missing-required-target binary-indep
E: ale source: debian-rules-missing-required-target binary-indep
E: arabtex source: debian-rules-missing-required-target binary-arch
E: autoconf source: debian-rules-missing-required-target binary-arch
E: babygimp source: debian-rules-missing-required-target binary-arch
E: backupninja source: debian-rules-missing-required-target binary-arch
E: bamboo source: debian-rules-missing-required-target binary-arch
E: bastille source: debian-rules-missing-required-target binary-indep
E: bazaar-doc source: debian-rules-missing-required-target binary-indep
E: bicyclerepair source: debian-rules-missing-required-target binary-arch
E: bitlbee source: debian-rules-missing-required-target binary-indep
E: blootbot source: debian-rules-missing-required-target binary-arch
E: blootbot source: debian-rules-missing-required-target binary-indep
E: boost-build source: debian-rules-missing-required-target binary-arch
E: boost-build source: debian-rules-missing-required-target build
E: bootcd source: debian-rules-missing-required-target binary-arch
E: br2684ctl source: debian-rules-missing-required-target binary-indep
E: c-cpp-reference source: debian-rules-missing-required-target build
E: c2n source: debian-rules-missing-required-target binary-indep
E: cacti source: debian-rules-missing-required-target binary-arch
E: camlidl-doc source: debian-rules-missing-required-target binary-arch
E: cassbeam source: debian-rules-missing-required-target binary-indep
E: check source: debian-rules-missing-required-target binary-indep
E: cli-common source: debian-rules-missing-required-target binary-arch
E: clips-doc source: debian-rules-missing-required-target build
E: coco-cs source: debian-rules-missing-required-target binary-arch
E: coco-doc source: debian-rules-missing-required-target binary-arch
E: coco-doc source: debian-rules-missing-required-target build
E: coco-doc source: debian-rules-missing-required-target clean
E: coco-java source: debian-rules-missing-required-target binary-arch
E: configure-debian source: debian-rules-missing-required-target binary-arch
E: cthumb source: debian-rules-missing-required-target build
E: dag2html source: debian-rules-missing-required-target binary-indep
E: db4.2 source: debian-rules-missing-required-target binary-indep
E: debget source: debian-rules-missing-required-target binary-arch
E: debroster source: debian-rules-missing-required-target binary-arch
E: dhcp source: debian-rules-missing-required-target binary-indep
E: dpkg-ftp source: debian-rules-missing-required-target build
E: drbdlinks source: debian-rules-missing-required-target binary-arch
E: drgeo-doc source: debian-rules-missing-required-target binary-arch
E: dupload source: debian-rules-missing-required-target binary-arch
E: dvipng source: debian-rules-missing-required-target binary-indep
E: e00compr source: debian-rules-missing-required-target binary-indep
E: efp source: debian-rules-missing-required-target binary-arch
E: emms source: debian-rules-missing-required-target binary-indep
E: enigmail source: debian-rules-missing-required-target build
E: fapg source: debian-rules-missing-required-target binary-indep
E: fbpanel source: debian-rules-missing-required-target binary-indep
E: filler source: debian-rules-missing-required-target binary-arch
E: flawfinder source: debian-rules-missing-required-target binary-arch
E: flowscan source: debian-rules-missing-required-target binary-arch
E: fortunes-ga source: debian-rules-missing-required-target binary-arch
E: fortunes-it source: debian-rules-missing-required-target binary-arch
E: freeswan source: debian-rules-missing-required-target binary-arch
E: freetype1 source: debian-rules-missing-required-target binary-indep
E: fv source: debian-rules-missing-required-target binary-indep
E: gap-ctbllib source: debian-rules-missing-required-target binary-arch
E: gap-matrix-schreiersims source: debian-rules-missing-required-target 
binary-arch
E: gkrellmitime source: debian-rules-missing-required-target binary-indep
E: gkrellweather source: debian-rules-missing-required-target binary-indep
E: gnoise source: debian-rules-missing-required-target binary-indep
E: gnome-lokkit source: debian-rules-missing-required-target binary-indep
E: gnucap source: debian-rules-mis

ethstatus: no upstream, RFA or removal?

[Christoph Haas]

Dear list...

I'm the maintainer of the "ethstatus" package - a console-based ethernet 
statistics monitor. You can e.g. run it on your gateway's 9" CRT on the 
console and see how much bandwidth is currently used in a bar-like view. 
I'm in the process of RFA'ing the package. But I wonder whether I should 
even request for this package to get removed.

Reasons:

(1) No real upstream

The former upstream developer - Gabriel Montenegro - has given up 
development of the package so I accepted to become the intermediate 
upstream contact in May 2003. I pimped the software a bit, wrote a 
manpage, fixed the code and copyright. But I did not really intend to stay 
the upstream developer for all times. After all my C knowledge is not 
exactly guru like. There is one minor bug filed against the package that I 
can't reproduce.

(2) There are similar packages

IMHO iptraf, iftop or nload serve similar purposes. So I wonder if yet 
another console network monitor is really needed.

(3) Few popcon installations

Popcon reports 282 installations for ethstatus.
iptraf: 2919 installations
iftop: 1057 installations
nload: 561 installations

So I would like to get a few comments before I request its removal. Mainly 
I'm unhappy with the missing upstream situation. I could also wait for a 
volunteer to maintain both the software and the maintainer. I'm personally 
just not that interested in the software any more.

Cheers
 Christoph
-- 
Famous coworker quote: "I'm still confused - just on a higher level now."


pgpS4ENAMufK0.pgp
Description: PGP signature

Re: safe halt/reboot/shutdown

[martin f krafft]

also sprach martin f krafft <[EMAIL PROTECTED]> [2006.10.17.1618 +0200]:
> Thus, unless I get other suggestions, I'll package it up in its
> own package, which diverts /sbin/{reboot,halt,shutdown} and puts
> my shell script in their place. I'll Enhance whatever init systems
> there are and I'll ask them to add Suggests.

http://debian.madduck.net/repo/dists/unstable/main/binary-all/admin/molly-guard_0.1_all.deb

I'll treat this discussion as an ITP and upload directly to NEW
after a few rounds of live tests.

Comments welcome.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
windoze is the one-night-stand of operating systems;
you feel so cheap after having used it.


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

Re: Fwd: How can the OS autodetect that a user is a newbie and offer help?

[Gustavo Noronha Silva]

Em Wed, 18 Oct 2006 10:26:26 -0200
"Yves Junqueira" <[EMAIL PROTECTED]> escreveu:

> It may be much cleaner to include help links /etc/motd, adivising the
> user to read a hipothetical
> "/usr/share/doc/linux-beginners/new-users", or enter a help-mode by
> typing a certain command.

Much cleaner, but I think newbie users do not really care about command
line. Those who care to learn will find one of the tutorials Jason
mentioned.

Either way, I think it would be a nice thing having motd point to some
'starter guide' tutorial. Here's a nice Progeny contribution that Osamu
'utnubued':

  http://www.debian.org/doc/manuals/users-guide/users-guide.en.html

It's not very translated, granted, but it could become =D

See you,

-- 
  Gustavo Noronha Silva <[EMAIL PROTECTED]>
http://www.debian.org/ | http://kov.eti.br/


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

Re: New source package

[Kevin Mark]

On Thu, Oct 19, 2006 at 09:47:10AM +0100, David Moore wrote:
>  Hi,
> 
> I have developed some new software, an audioscrobbler client for 
> _l_a_s_t_._f_m, which
> I would
> like to see included, probably under Multimedia.
> 
> It consists of two simple C source files - how do I go about getting it
> included
> in Debian?
> 
> Cheers,
Hi David,
In the Debian Bug tracking system, there is a pseudo-package[0] call
wnpp[1] that you file a ITP 'bug' (Intent to Package) against which
states your intention to create a Debian package. If you are not a
Debian Developer, you will need a 'sponsor' for your package. This
person will inspect your package for numerous things including trojans,
bugs, and Debian policy violation. If its OK, that person will upload it
into the 'incoming' server[2] where it will propagate to the 'unstable'
branch of Debian. The easiest way to file a wnpp bug is to use the
Debian program 'reportbug' for your ITP. Fill in all the required
details or it will be rejected. Read the MAN pages for info. You should
check out the Debian Developer subsite[3] and start by reading the
Debian new maintainers guide[4]. You should also read the Debian developers
reference and Debian policy manual for complete detains on how to create
a Debian package up to Debian Standards. You can join the debian-mentors
list for help with creating a Debian package. Also, when you create your
ITP, folks may question the need for the package for various reasons
like:
are you sure the license is DFSG free?
is there already a similar program in Debian?
if so, why do we need this one?
Could you add it to an existing package, if its a small program?

Don't be discouraged if you are asked, as folks want to make sure that
software in Debian is not simply a one-line shell script or the 24th
version of vi. And if you are really brave and patient, you can join the
Debian new maintainer queue and join the ranks as a voting member of
Debian.
here's to seeing your package in Debian!
Kev

[0] http://www.debian.org/Bugs/pseudo-packages
[1] http://bts.debian.org/wnpp
[2] http://incoming.debian.org
[3] http://www.debian.org/devel/
[4] http://www.debian.org/doc/maint-guide/
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Fwd: How can the OS autodetect that a user is a newbie and offer help?

[Eduard Bloch]

#include 
* Thomas Viehmann [Thu, Oct 19 2006, 10:58:42AM]:
> Wouter Verhelst wrote:
> > Or we could mimic FreeBSD behaviour: create a fortune-file with helpful
> > tips for newbies, and add a line in the default initialization files
> > (i.e., those in /etc/skel) for different shells that calls fortune for
> > those tips.
> 
> You mean like fortunes-debian-hints[1]?

IMO that's a bit too advanced, too administrator/developer specific.
I would prefer having a fortunes-newbie-hints which is mixed by fortune,
eg. using 90% from newbie-hints and 10% from debian-hints. I would even
change that during the runtime, eg. shifting the weights by one percent
every day, from newbie-hints to debian-hints.

Eduard.

-- 
* Scorpi ist aus dem Amiga-Bereich eher Boards gewöhnt, die man nach dem
Rausschrauben nur unter Umgehung physicher Gesetze wieder eingebaut
bekommt.


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

Re: New source package

[Wouter Verhelst]

On Thu, Oct 19, 2006 at 09:47:10AM +0100, David Moore wrote:
> Hi,
> 
> I have developed some new software, an audioscrobbler client for last.fm,
> which I would
> like to see included, probably under Multimedia.
> 
> It consists of two simple C source files - how do I go about getting it
> included
> in Debian?

Two options: 
* File an RFP ("reportbug wnpp") and hope someone will package it for
  you.
* Read the documentation on how to package something, and try to find a
  sponsor who will upload it for you. You will have more success on
  debian-mentors than this mailinglist if you go down that road.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: Fwd: How can the OS autodetect that a user is a newbie and offer help?

[Wouter Verhelst]

On Thu, Oct 19, 2006 at 10:58:42AM +0200, Thomas Viehmann wrote:
> Wouter Verhelst wrote:
> > Or we could mimic FreeBSD behaviour: create a fortune-file with helpful
> > tips for newbies, and add a line in the default initialization files
> > (i.e., those in /etc/skel) for different shells that calls fortune for
> > those tips.
> 
> You mean like fortunes-debian-hints[1]?

Probably. So all that is left now is make sure it gets in the default
.bashrc

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

New source package

[David Moore]

Hi,



I have developed some new software, an audioscrobbler client for last.fm, which I would 

like to see included, probably under Multimedia. 



It consists of two simple C source files - how do I go about getting it included

in Debian?



Cheers,

David.



[EMAIL PROTECTED] -- 
http://dmctek.googlepages.com

Re: Fwd: How can the OS autodetect that a user is a newbie and offer help?

[Thomas Viehmann]

Wouter Verhelst wrote:
> Or we could mimic FreeBSD behaviour: create a fortune-file with helpful
> tips for newbies, and add a line in the default initialization files
> (i.e., those in /etc/skel) for different shells that calls fortune for
> those tips.

You mean like fortunes-debian-hints[1]?

Kind regards

T.

1. http://packages.debian.org/fortunes-debian-hints
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: Fwd: How can the OS autodetect that a user is a newbie and offer help?

[Wouter Verhelst]

On Wed, Oct 18, 2006 at 10:26:26AM -0200, Yves Junqueira wrote:
> It may be much cleaner to include help links /etc/motd, adivising the
> user to read a hipothetical
> "/usr/share/doc/linux-beginners/new-users", or enter a help-mode by
> typing a certain command.

Or we could mimic FreeBSD behaviour: create a fortune-file with helpful
tips for newbies, and add a line in the default initialization files
(i.e., those in /etc/skel) for different shells that calls fortune for
those tips.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Problems in PMDF Mailserv V6.1 command processing

[PMDF Mailserv V61]

Error in the command: The original message was received at Thu, 19 Oct 2006 
14:05:57 +0600 from 177.180.128.188
Unrecognized command verb: THE
Subsequent commands ignored because of previous error.
Ignored: - The following addresses had permanent fatal errors -
Ignored: <[EMAIL PROTECTED]>
Use the HELP command to get a list of legal MAILSERV commands.


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