Re: new cogito package, OpenSSL license issue resolved

[Christoph Hellwig]

On Fri, May 13, 2005 at 11:44:05PM -0600, Sebastian Kuzminsky wrote:
> I've updated the Cogito package to compile against the upstream-included
> GPL SHA1 implementation lifted from Mozilla, instead of the (possibly)
> GPL-incompatible OpenSSL code.  Thanks to Florian Weimer and Anibal
> Monsalve Salazar for bringing this issue to my attention.  I have a
> terrible head for this kind of legal stuff, "can't we all just get
> the code?"
> 
> 
> This is the last issue I know of keeping this package out of the Debian
> archives.  Yay!  There's still the manpage issue, but I expect it will
> be resolved upstream in the next few days.

Any chance you can make the package use the included assemly sha1
implementation on powerpc?  It's a notable difference and with that
change I could switch from self-compiled cognito to the package.


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

Re: packages missing from sarge

[Thomas Hood]

On Wed, 11 May 2005 12:30:21 +0200, Adrian Bunk wrote:
> Completely MIA maintainers are one part of the problem.
> 
> But then there's the class of maintainers who manage to upload a new 
> upstream version and perhaps fix some RC bugs every few months but are 
> not able to properly handle all bugs in their packages.


In part this is a consequence of scarce manpower.  In part it is a
consequence of the institution of package ownership and other
organisational flaws. If you agree with this diagnosis then I am curious
to know which of the following you plan to do.

1. continue to participate in the Debian project despite its
   dysfunctional organisation;
2. push for changes to the organisation;
3. participate in another project instead.

(There are other possibilities, of course.)

-- 
Thomas Hood


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

eSecure Online Pharmacies

[Dorothy]

refill your prescription online
http://jiga.pmsit8pi4hpxbqp.meshednlngh.com

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

Hello

[Olga]

Hello!!! My name is Olga. 
I live in Russia. I have seen your profile and  decided to get to know you better.
A few words about myself: I am searching serious relationships - if you want just to play with me I ask you not to answer on this letter! 
But if you want to find LOVE -my email:  [EMAIL PROTECTED]

I will send my picture after your answer in the next letter. 
I will wait your answer with great impatience.  Hope to hear from you very soon!!!
email:  [EMAIL PROTECTED]

sincere yours,  Olga...
UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RC bug #308477 and MIA maintainer (?)

[Bill Allombert]

On Thu, May 12, 2005 at 07:59:33PM -0700, Steve Langasek wrote:
> severity 308477 important
> thanks
> 
> You are correct that it is a policy violation.  However, not all policy
> violations are release-critical for a given release; see

Maybe I will sound procedural or something, but I would really prefer
if such policy violation bug were severity serious with a sarge-ignore
tag. It is important to keep track of policy violation bug that affect
sid, and it will be hard to remember all bugs that should have their
severity raised once sarge is released.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: RC bug #308477 and MIA maintainer (?)

[Steve Langasek]

On Sat, May 14, 2005 at 05:59:07AM -0500, Bill Allombert wrote:
> On Thu, May 12, 2005 at 07:59:33PM -0700, Steve Langasek wrote:
> > severity 308477 important
> > thanks

> > You are correct that it is a policy violation.  However, not all policy
> > violations are release-critical for a given release; see

> Maybe I will sound procedural or something, but I would really prefer
> if such policy violation bug were severity serious with a sarge-ignore
> tag. It is important to keep track of policy violation bug that affect
> sid, and it will be hard to remember all bugs that should have their
> severity raised once sarge is released.

As it's been explained to me by the BTS folks, use of sarge-ignore implies
that the bug will become RC for etch immediately after sarge's release.  For
this bug, I don't see any reason to think that's the case.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: RC bug #308477 and MIA maintainer (?)

[Bill Allombert]

On Sat, May 14, 2005 at 04:23:02AM -0700, Steve Langasek wrote:
> On Sat, May 14, 2005 at 05:59:07AM -0500, Bill Allombert wrote:
> > On Thu, May 12, 2005 at 07:59:33PM -0700, Steve Langasek wrote:
> > > severity 308477 important
> > > thanks
> 
> > > You are correct that it is a policy violation.  However, not all policy
> > > violations are release-critical for a given release; see
> 
> > Maybe I will sound procedural or something, but I would really prefer
> > if such policy violation bug were severity serious with a sarge-ignore
> > tag. It is important to keep track of policy violation bug that affect
> > sid, and it will be hard to remember all bugs that should have their
> > severity raised once sarge is released.
> 
> As it's been explained to me by the BTS folks, use of sarge-ignore implies
> that the bug will become RC for etch immediately after sarge's release.  For
> this bug, I don't see any reason to think that's the case.

Is it really a problem ? Is not the bug worth fixing ? 

Why not rename sarge-ignore to etch-ignore once sarge is released ?
Why not both downgrade and tag the bug, or something ?

I am concerned because in effect that hijack the definition of the
serious severity (which is 'violate a must in the debian-policy')
administrated by the Debian policy group.

It is my understanding that the sarge-ignore tag was introduced for the
express purpose to allow the Release team to define the release policy
without stepping of the foot of the Debian policy group. If sarge-ignore
is not suitable for that task, then we should reconsider its
implementation.

The Debian policy update follows an open process and is an important
part of Debian. It should keep authority on the serious severity.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: new cogito package, OpenSSL license issue resolved

[Sebastian Kuzminsky]

Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Fri, May 13, 2005 at 11:44:05PM -0600, Sebastian Kuzminsky wrote:
> > I've updated the Cogito package to compile against the upstream-included
> > GPL SHA1 implementation lifted from Mozilla, instead of the (possibly)
> > GPL-incompatible OpenSSL code.  Thanks to Florian Weimer and Anibal
> > Monsalve Salazar for bringing this issue to my attention.  I have a
> > terrible head for this kind of legal stuff, "can't we all just get
> > the code?"
> > 
> > 
> > This is the last issue I know of keeping this package out of the Debian
> > archives.  Yay!  There's still the manpage issue, but I expect it will
> > be resolved upstream in the next few days.
> 
> Any chance you can make the package use the included assemly sha1
> implementation on powerpc?  It's a notable difference and with that
> change I could switch from self-compiled cognito to the package.


I've updated my Cogito source package (0.10+20050513-3) to use the
ppc-sha1 on powerpc, but I dont have a powerpc machine to compile on,
so I haven't tested it.  It still uses mozilla-sha1 on all the other
architectures.


Please pull the sources via http or apt and let me know if it works!


http://highlab.com/~seb/debian

-or-

# Seb's packages from highlab.com
deb http://highlab.com/~seb/debian /
deb-src http://highlab.com/~seb/debian /




--
Sebastian


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

alioth mailing list moderation broken for extended period of time

[Marc Haber]

Hi,

since more than a month now, mailing list moderation on alioth is
broken. $LIST-admin bounces, and so the list admin does not receive
any notice about messages being in the moderation queue, unnecessarily
delaying message running times and making communication harder.

A corresponding ticket in the alioth site admin tracker is unanswered,
and asking on the alioth IRC channel (which usually works to get help)
is ignored.

So I need to ask here whether it would be a better idea to move
mailing lists away from obviously broken, unmaintained and unsupported
infrastructure like alioth currently is.

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

Re: alioth mailing list moderation broken for extended period of time

[Martin Mewes]

Hi Marc,

Marc Haber <[EMAIL PROTECTED]> wrote :

> So I need to ask here whether it would be a better idea to move
> mailing lists away from obviously broken, unmaintained and
> unsupported infrastructure like alioth currently is.

If there is any $LIST-admin-position somewhat orphaned I would happily 
volunteer to take over the service if this helps.

bis dahin/kind regards

Martin Mewes

-- 
Welche Mailingliste zu welchem Linux?
suse-linux@suse.com ->  SuSE Linux
debian-user-german@lists.debian.org ->  Debian GNU/Linux
linux-kernel@vger.kernel.org->  Linux Kernel


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

Re: packages missing from sarge

[=?iso-8859-1?q?Fran=E7ois-Denis_Gonthier?=]

On May 7, 2005 09:03 pm, Joey Hess wrote:

> erlang

Erlang and the related erlang-manpages and erlang-doc-html are being put 
up-to-date by me.  I have a package ready which should be uploaded by my 
sponsor in the coming week.

I guess that means that the package that reverse depends on Erlang would also 
be allowed back on:

  wings3d
  manderlbot
  ejabberd
  devel-protocols

(I tested wings3d with my package and it works fine!)

I would like to know if it still possible to get it into Sarge and what if 
yes, what do I need to verify? 

BTW, if Erlang 10.B.5 gets into Sarge, the package libxmerl-erlang will be 
obsoleted.  xmerl has been integrated in the main Erlang distribution since 
version 10.  I think I will check with the maintainer.

François-Denis Gonthier


pgptJzeUglqL2.pgp
Description: PGP signature

=?windows-1251?B?xfm4IOLu7/Du8fs=?=

[Vadim Petrunin]

Всем доброго времени суток
Спасибо за отвёты на прёдыдущёё письмо, но я, правда, не увидел ответов на  
1-й вопрос. Сделал вывод, что очевидно ответ на вопрос #2 относится также  
и ко 1-му вопросу. На всякий случай спрошу еще раз, с уточнениями:
Для того чтобы перевести что-то на русский язык необходимо
1. взять из глобального Debian-CVS или из локально скачанного пакета .pot  
файл
2. создать ru.po
3. добавить этот файл в CVS l10n-russian (дабы потвердить намерение  
переводить этот пакет)
4. переводить, коммитить.
[5. сообщать в рассылке об окончании перевода.]

Верно ли написаное выше и, если да, распространяется ли это на Debian  
Installer? Как, все таки, определить : не переводит ли этот файл еще  
кто-то помимо меня (я про .po-файлы D-i).

Далее: почему у нас в CVS/installer пакет discover1 находится в level3, а  
в глобальном -- в level4?
см
http://people.debian.org/~seppy/d-i/level3/ru.txt
http://people.debian.org/~seppy/d-i/level4/ru.txt
Хотя, я думаю, ссылки можно было не приводить.

Да, кстати, в рассылке принято общаться на "вы" или на "ты"? :)
С уважением, Вадим
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Please, sorry

[Vadim Petrunin]

Sorry! I have mixed addresses up in my previous message.
It was not for debian-devel
Vadim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: packages missing from sarge

[Steve Langasek]

On Sat, May 14, 2005 at 05:44:33PM -0400, François-Denis Gonthier wrote:
> On May 7, 2005 09:03 pm, Joey Hess wrote:

> > erlang

> Erlang and the related erlang-manpages and erlang-doc-html are being put 
> up-to-date by me.  I have a package ready which should be uploaded by my 
> sponsor in the coming week.

> I guess that means that the package that reverse depends on Erlang would also 
> be allowed back on:

No, this is a package that was not in woody, so it's going to be too late
to get it (and its reverse-deps) into sarge.  The release team is not going
to spend its time hand-holding packages that were nowhere near releasable at
the time of freeze when there are still 50+ RC bugs that need to be fixed
before we release.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Against which package should this go?

[Roberto C. Sanchez]

I have recently come to the conclusion that it would be
nice for messages that are to the BTS and get reflected
via email have a URL for the bug itself.  I thought I
would file a wishlist bug for it, but I am not sure
against which pacakge it should be filed.  Is there a
BTS package?  Would that be the appropriate place for it?

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


signature.asc
Description: OpenPGP digital signature

Re: Against which package should this go?

[Roberto C. Sanchez]

Roberto C. Sanchez wrote:
> I have recently come to the conclusion that it would be
> nice for messages that are to the BTS and get reflected
> via email have a URL for the bug itself.  I thought I
> would file a wishlist bug for it, but I am not sure
> against which pacakge it should be filed.  Is there a
> BTS package?  Would that be the appropriate place for it?
> 
> -Roberto
> 

Upon second reading, this really doesnt make much sense.
Let me clarify.

If the BTS sends out an email (to -devel, the submitter,
wherever) that is a reflection of a new bug report or
something that was added to a bgu report, a URL should
be included.  That is, if I submit a bug report and it
is assigned #123456 and that report is then sent on to
the maintainer and d-d, then it should have a URL at the
bottom of the form http://bugs.debian.org/123456

Maybe its completely superfluous, but I thought I would
at least bring it up.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


signature.asc
Description: OpenPGP digital signature

Re: Against which package should this go?

[Peter Samuelson]

[Roberto C. Sanchez]
> If the BTS sends out an email (to -devel, the submitter, wherever)
> that is a reflection of a new bug report or something that was added
> to a bgu report, a URL should be included.  That is, if I submit a
> bug report and it is assigned #123456 and that report is then sent on
> to the maintainer and d-d, then it should have a URL at the bottom of
> the form http://bugs.debian.org/123456

File it against the 'bugs.debian.org' package name.  See
http://www.debian.org/Bugs/pseudo-packages for a list of package names
to file bugs against when they aren't bugs in specific Debian packages.

Peter


signature.asc
Description: Digital signature

Re: Against which package should this go?

[Roberto C. Sanchez]

Peter Samuelson wrote:
> [Roberto C. Sanchez]
> 
>>If the BTS sends out an email (to -devel, the submitter, wherever)
>>that is a reflection of a new bug report or something that was added
>>to a bgu report, a URL should be included.  That is, if I submit a
>>bug report and it is assigned #123456 and that report is then sent on
>>to the maintainer and d-d, then it should have a URL at the bottom of
>>the form http://bugs.debian.org/123456
> 
> 
> File it against the 'bugs.debian.org' package name.  See
> http://www.debian.org/Bugs/pseudo-packages for a list of package names
> to file bugs against when they aren't bugs in specific Debian packages.
> 
> Peter

Thanks for the pointer.  Apparently, someone came up with this idea
about 8 years ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=9596

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


signature.asc
Description: OpenPGP digital signature

Re: Against which package should this go?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Maybe its completely superfluous, but I thought I would
> at least bring it up.

I think it is a good idea. Even if we dont move to a web based system there
is no harm to support us web browser users a bit :)

And consider especially the end-user. 

Greetings


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

gwrapguile: Question about suitability of changes for sarge

[Andreas Rottmann]

[Resent message, first one seemingly didn't get thru]

Hi!

I prepared an upload for gwrapguile and fix #308499. The changelog
looks like this:

  * Move /usr/bin/g-wrap-config to libgwrapguile-dev (closes: #308499).
  * Include manpage for g-wrap-config.
  * Make libgwrapguile-dev depend on guile, since g-wrap-config is a
guile script.
  * g-wrap.m4: Fix underquoted definitions (closes: #274478).
  * Build-Depend on debhelper (>> 4).
  * Bump policy version to 3.6.1 (no changes).
  * Fix malformed jgoerzen email address in changelog.

These are all changes that have little or no impact (besides the one
fixing #308499), but fix packaging issues. So my question is: would
the above be suitable to go into sarge, or should I prepare an upload
that just fixes #308499?

Thanks, Rotty
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://yi.org/rotty  | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

Python is executable pseudocode, Perl is executable line-noise.


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

Re: adduser: what is the difference between --disabled-password and--disabled-login

[Brian May]

> "Marc" == Marc Haber <[EMAIL PROTECTED]> writes:

Marc> If that option is switched off, an account created with
Marc> adduser --disabled-login is impossible to ssh into (log
Marc> entry "sshd[14704]: User testuser not allowed because
Marc> account is locked") while an account created with adduser
Marc> --disabled-password can ssh in fine via authorized_keys.

I would speculate that the pam_unix module doesn't support checking
the account is locked or not, it only checks to see if it can match
the password. However, as no password is used...

Is there any reason why pam_unix doesn't check if the account is
locked?

Along similar lines, I have noticed general weirdness with pam_ldap.

According to tests I just conducted (OK means login allowed, Fail
means login failed):

| password   | RSA
| courier-imap | openssh | openssh 
+--+-+
expired password| OK   | Fail[1] | Fail[2]
account deactive[3] | Fail | Fail| OK
--

I find this inconsistency is very confusing. What happened (in my
case) is most users on my system log in via courier-imap and never
realize that their password has expired, because it continued
working. Then they came to a trivial problem that took ages to fix
because first I had to debug why ssh wouldn't let them log in using a
password.

I also find it incredible that an expired LDAP password will prevent
RSA based log ins (WHY?), but a deactive account won't (WHY not?).

I also think it would be really "cool"(TM) if the system could display
a message "password expired" or "account is locked" if the user
successfully authenticates to the system but is unable to authorize
the user to use the system. This saves the user wondering "did I use
the correct password?", "Did I enter it in correctly?", etc.

Notes:

[1] Nothing displayed to user, but following logged:

May 15 10:46:24 snoopy sshd[15018]: error: PAM: User account has expired for 
jan from localhost

[2] Automatically reverts to password based authentication which
fails, but in this case it never displays the expired message.

May 15 10:50:53 snoopy sshd[15846]: error: PAM: Authentication failure for jan 
from localhost

[3] "Account deactivated" option in "LDAP Account Manager". I haven't
worked out how this is stored in LDAP yet. No messages displayed to
the user.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: adduser: what is the difference between --disabled-password and--disabled-login

[Steve Langasek]

On Sun, May 15, 2005 at 11:19:12AM +1000, Brian May wrote:
> > "Marc" == Marc Haber <[EMAIL PROTECTED]> writes:
> 
> Marc> If that option is switched off, an account created with
> Marc> adduser --disabled-login is impossible to ssh into (log
> Marc> entry "sshd[14704]: User testuser not allowed because
> Marc> account is locked") while an account created with adduser
> Marc> --disabled-password can ssh in fine via authorized_keys.

> I would speculate that the pam_unix module doesn't support checking
> the account is locked or not, it only checks to see if it can match
> the password.

That's incorrect.

> Is there any reason why pam_unix doesn't check if the account is
> locked?

It does, if you use the authorization checks in PAM.  If you only use the
authentication checks, then PAM is only going to authenticate the user --
not check whether they're allowed access.

> I also think it would be really "cool"(TM) if the system could display
> a message "password expired" or "account is locked" if the user
> successfully authenticates to the system but is unable to authorize
> the user to use the system. This saves the user wondering "did I use
> the correct password?", "Did I enter it in correctly?", etc.

This leaks information to attackers about the state of the account.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: adduser: what is the difference between --disabled-password and--disabled-login

[Glenn Maynard]

On Sat, May 14, 2005 at 07:22:56PM -0700, Steve Langasek wrote:
> > I also think it would be really "cool"(TM) if the system could display
> > a message "password expired" or "account is locked" if the user
> > successfully authenticates to the system but is unable to authorize
> > the user to use the system. This saves the user wondering "did I use
> > the correct password?", "Did I enter it in correctly?", etc.
> 
> This leaks information to attackers about the state of the account.

Hence "could": I don't consider the fact that an account is expired or
locked (or exists, for that matter) to be sensitive information, for
my uses, and would much prefer to give proper error messages.  People
with different security needs/philosophies use different policies ...

(I'd be satisfied if I could convinced logins/su to not force a pointless
delay on an incorrect password--the only thing more annoying than mistyping
my password is having my own system force me to wait.  One of these days I'll
get annoyed enough by this to track down why "FAIL_DELAY 0" isn't being
honored ...)

-- 
Glenn Maynard


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

Re: adduser: what is the difference between --disabled-password and--disabled-login

[Steve Langasek]

On Sat, May 14, 2005 at 10:33:28PM -0400, Glenn Maynard wrote:
> On Sat, May 14, 2005 at 07:22:56PM -0700, Steve Langasek wrote:
> > > I also think it would be really "cool"(TM) if the system could display
> > > a message "password expired" or "account is locked" if the user
> > > successfully authenticates to the system but is unable to authorize
> > > the user to use the system. This saves the user wondering "did I use
> > > the correct password?", "Did I enter it in correctly?", etc.

> > This leaks information to attackers about the state of the account.

> Hence "could": I don't consider the fact that an account is expired or
> locked (or exists, for that matter) to be sensitive information, for
> my uses, and would much prefer to give proper error messages.  People
> with different security needs/philosophies use different policies ...

The trouble with doing this, in PAM-based systems, is that authentication
precedes authorization; so any message that informs the user that the
account is not authorized (i.e., it's expired or locked) also informs the
attacker that authentication succeeded.

So, it's not just information about the account state that's being leaked;
you're also leaking authentication tokens.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: RC bug #308477 and MIA maintainer (?)

[Steve Langasek]

On Sat, May 14, 2005 at 07:33:01AM -0500, Bill Allombert wrote:
> On Sat, May 14, 2005 at 04:23:02AM -0700, Steve Langasek wrote:
> > On Sat, May 14, 2005 at 05:59:07AM -0500, Bill Allombert wrote:
> > > On Thu, May 12, 2005 at 07:59:33PM -0700, Steve Langasek wrote:
> > > > severity 308477 important
> > > > thanks

> > > > You are correct that it is a policy violation.  However, not all policy
> > > > violations are release-critical for a given release; see

> > > Maybe I will sound procedural or something, but I would really prefer
> > > if such policy violation bug were severity serious with a sarge-ignore
> > > tag. It is important to keep track of policy violation bug that affect
> > > sid, and it will be hard to remember all bugs that should have their
> > > severity raised once sarge is released.

> > As it's been explained to me by the BTS folks, use of sarge-ignore implies
> > that the bug will become RC for etch immediately after sarge's release.  For
> > this bug, I don't see any reason to think that's the case.

> Is it really a problem ? Is not the bug worth fixing ? 

> Why not rename sarge-ignore to etch-ignore once sarge is released ?
> Why not both downgrade and tag the bug, or something ?

> I am concerned because in effect that hijack the definition of the
> serious severity (which is 'violate a must in the debian-policy')
> administrated by the Debian policy group.

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

, emphasis added; note the
link to the sarge RC policy.

The definition of serious, as indicated by the BTS admins, includes RM
oversight.

The bug in question doesn't actually break anything, so adherence to policy
is not release-critical; this won't change with the release of sarge, or
even with the release of etch.

> It is my understanding that the sarge-ignore tag was introduced for the
> express purpose to allow the Release team to define the release policy
> without stepping of the foot of the Debian policy group. If sarge-ignore
> is not suitable for that task, then we should reconsider its
> implementation.

> The Debian policy update follows an open process and is an important
> part of Debian. It should keep authority on the serious severity.

AIUI, the BTS admins have authority over the meaning of the different
severities and tags.  I have no opinion on the matter, as long as there is
some means the release team can use to differentiate between bugs that need
to be addressed before the release, and those that don't.  In this case, I'm
merely following what I understand to be the recommendation of the BTS
admins.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: alioth mailing list moderation broken for extended period of time

[Marc Haber]

On Sat, 14 May 2005 22:06:42 +0200, Martin Mewes <[EMAIL PROTECTED]> wrote:
>Marc Haber <[EMAIL PROTECTED]> wrote :
>> So I need to ask here whether it would be a better idea to move
>> mailing lists away from obviously broken, unmaintained and
>> unsupported infrastructure like alioth currently is.
>
>If there is any $LIST-admin-position somewhat orphaned I would happily 
>volunteer to take over the service if this helps.

This problem is not one of a MIA list moderator. It is a technical
issue.

One of the $LIST values I know as "clearly affected" is
pkg-exim4-users, and I currently serve as one of the targets for
pkg-exim4-users-admin. At least, that's what the mailman frontend of
alioth says, but [EMAIL PROTECTED] bounces
nevertheless: pipe to |/var/lib/mailman/mail/wrapper admin
pkg-exim4-users generated by
[EMAIL PROTECTED], Illegal command: admin

I firmly believe that this is a technical problem with the mailing
list setup on alioth, and the corresponding alioth site admin tracker
item 301440.

This problem affects all alioth mailing lists that I am admin for,
which includes the lists for pkg-exim4, pkg-torrus and adduser.

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