Difference between A and C (was: Call for votes ...)

[martin f krafft]

The difference between proposals A and C wasn't clear to me at
first, so at Manoj's request, I am sharing it with everyone. If you
read carefully, you won't need this, I guess.

> Proposal A: Clarifies status of non-technical documents.  Creates
> Foundation Documents class which requires 3:1 majority to change and
> includes the Social Contract and the DFSG.
>
> [...]
>
> +   5.2 The Foundation Documents are the works entitled "Debian
> +   Social Contract" and "Debian Free Software Guidelines".

[...]

> Proposal C: Clarifies status of non-technical documents.  Creates
> Foundation Documents class which requires 3:1 majority to change and
> includes _only_ the Social Contract, and *not* the DFSG.
>
> [...]
>
> +   5.2 The Foundation Document is the work entitled "Debian
> +   Social Contract".

As you can see, the only difference is that proposal A calls the
Social Contract *and* the DFSG a foundation document in section 5.2.
Proposal C only calls the social contract a foundation document.

Hope this clears it up for some.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpjgVLJpCJRf.pgp
Description: PGP signature

Re: Bug#215556: ITP: gsysutils -- Set of utilities useful to system administrators

[Bob Proulx]

Andreas Rottmann wrote:
> >> Btw, "sysutils" is taken, so I take "gsysutils". Does someone prefer
> >> "gnu-sysutils"?
> >
> > I would, as I associate gsomething with a Gnome-frontend for something
> > (e.g gsudo), but I don't claim that is common conception.
> >
> Well, I can back that up. A Gnome association swept to the surface of
> my mind when I read the package name, too,

If you are asking for votes then I as well prefer something other than
gsysutils and gnu-sysutils seems appropriate.

Bob

Pre-Depends for postgresql

[Martin Pitt]

Hi!

The package postgresql needs to use 'adduser' and 'addgroup' in its
preinst script to properly save the current database before upgrading
(cf. Bug #180199). Therefore it should pre-depend on 'adduser'.

Pre-Dependencies are supposed to be discussed at d-devel which I want
to do now. If anybody objects I will just do it.

Thanks and have a nice day!

Martin
-- 
Martin Pitt
home:  www.piware.de
eMail: [EMAIL PROTECTED]

Re: Bug#215556: ITP: gsysutils -- Set of utilities useful to system administrators

[Mathieu Roy]

[EMAIL PROTECTED] (Bob Proulx) a tapoté :

> Andreas Rottmann wrote:
> > >> Btw, "sysutils" is taken, so I take "gsysutils". Does someone prefer
> > >> "gnu-sysutils"?
> > >
> > > I would, as I associate gsomething with a Gnome-frontend for something
> > > (e.g gsudo), but I don't claim that is common conception.
> > >
> > Well, I can back that up. A Gnome association swept to the surface of
> > my mind when I read the package name, too,
> 
> If you are asking for votes then I as well prefer something other than
> gsysutils and gnu-sysutils seems appropriate.

Considering the content of the current Debian sysutils package, way
less important than the gnu sysutils package IMHO, described as
"Miscellaneous small system utilities", maybe it would be possible, if
the maintainer of this package agree, to rename the current sysutils? 

(with the Debian conflicts/replaces fields in control file, it should
be feasible without harm)

The current sysutils contains:

 * procinfo - Displays system information from /proc (v17).
 *   memtest - Test system memory for errors (v2.93.1).
 *  bogomips - Shows the current bogomips rating without rebooting (v1.2).
 * tofromdos - Converts DOS <-> Unix text files (v1.4).

http://packages.debian.org/stable/utils/sysutils.html

(anyway what's the difference between tofromdos and
dos2unix/unix2dos?)  

Another solution would be to make a debian package that contain these
software along with the gnu sysutils tools.





-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: Pre-Depends for postgresql

[Matthew Palmer]

On Thu, Oct 16, 2003 at 11:00:47AM +0200, Martin Pitt wrote:

> Pre-Dependencies are supposed to be discussed at d-devel which I want
> to do now. If anybody objects I will just do it.

Doesn't that kind of defeat the purpose of discussing these sorts of things?

As it stands, I don't see a problem with the pre-depends, but your attitude
is... disquieting.

- Matt

Re: Pre-Depends for postgresql

[Martin Pitt]

Hi!

On 2003-10-16 19:24 +1000, Matthew Palmer wrote:
> On Thu, Oct 16, 2003 at 11:00:47AM +0200, Martin Pitt wrote:
> 
> > Pre-Dependencies are supposed to be discussed at d-devel which I want
> > to do now. If anybody objects I will just do it.
> 
> Doesn't that kind of defeat the purpose of discussing these sorts of things?
> 
> As it stands, I don't see a problem with the pre-depends, but your attitude
> is... disquieting.

Please take my excuse, I guess my English fooled me this morning. I
just read that again and see what you are meaning...

Actually I meant "if nobody objects I will do it" (*slapping my
head*). In the sense that I don't require twenty replies saying just
"yes", but would rather be interested in opinions why it should _not_
be done.

Sorry again and have a nice day!

Martin
--
Martin Pitt
home:  www.piware.de
eMail: [EMAIL PROTECTED]

Re: Pre-Depends for postgresql

[Colin Watson]

On Thu, Oct 16, 2003 at 07:24:21PM +1000, Matthew Palmer wrote:
> On Thu, Oct 16, 2003 at 11:00:47AM +0200, Martin Pitt wrote:
> > Pre-Dependencies are supposed to be discussed at d-devel which I
> > want to do now. If anybody objects I will just do it.
> 
> Doesn't that kind of defeat the purpose of discussing these sorts of
> things?
> 
> As it stands, I don't see a problem with the pre-depends, but your
> attitude is... disquieting.

To me, it read like a typo for "If nobody objects".

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Pre-Depends for postgresql

[Russell Coker]

On Thu, 16 Oct 2003 19:00, Martin Pitt wrote:
> The package postgresql needs to use 'adduser' and 'addgroup' in its
> preinst script to properly save the current database before upgrading
> (cf. Bug #180199). Therefore it should pre-depend on 'adduser'.

Why would there be an issue on depending on a more important package?

Having an optional/misc package pre-depend on an important/base package seems 
like a non-issue to me.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Pre-Depends for postgresql

[Martin Pitt]

Hi Russell and all others,

On 2003-10-16 21:39 +1000, Russell Coker wrote:
> On Thu, 16 Oct 2003 19:00, Martin Pitt wrote:
> > The package postgresql needs to use 'adduser' and 'addgroup' in its
> > preinst script to properly save the current database before upgrading
> > (cf. Bug #180199). Therefore it should pre-depend on 'adduser'.
> 
> Why would there be an issue on depending on a more important package?
> 
> Having an optional/misc package pre-depend on an important/base package seems 
> like a non-issue to me.

adduser is neither essential nor required, thus does not need to be
installed when installing postgres.  I'm not quite sure what you mean,
could you please explain this?

Thanks in advance!

Martin

P.S. No need to CC me, I'm subscribed (see mail-followup-to). Thanks.
-- 
Martin Pitt
home:  www.piware.de
eMail: [EMAIL PROTECTED]

Re: Bug#215945: ITP: etw -- arcade-style soccer game

[Sam Hocevar]

On Wed, Oct 15, 2003, Sam Hocevar wrote:

> * Package name: etw
> 
>  Eat The Whistle is an arcade soccer game similar to famous Amiga titles such
>  as Kick Off or Sensible Soccer. It features several game modes where you can
>  play either as the whole team or as a single player, and you can also manage
>  teams that take part in cups and leagues. There is even an arcade mode with
>  powerups and bonuses, like in the game SpeedBall 2.

   The game is really great, but has still many bugs. I don't want to
upload it in unstable until I have improved the overall stability, but
in the meantime you can find my preliminary packages here:

 deb http://sam.zoy.org/projects/debian sid main
 deb-src http://sam.zoy.org/projects/debian sid main

   (The data package is 11 MB, be warned)

Regards,
-- 
Sam.

Re: Pre-Depends for postgresql

[Mathieu Roy]

Martin Pitt <[EMAIL PROTECTED]> a tapoté :

> Hi Russell and all others,
> 
> On 2003-10-16 21:39 +1000, Russell Coker wrote:
> > On Thu, 16 Oct 2003 19:00, Martin Pitt wrote:
> > > The package postgresql needs to use 'adduser' and 'addgroup' in its
> > > preinst script to properly save the current database before upgrading
> > > (cf. Bug #180199). Therefore it should pre-depend on 'adduser'.
> > 
> > Why would there be an issue on depending on a more important package?
> > 
> > Having an optional/misc package pre-depend on an important/base package 
> > seems 
> > like a non-issue to me.
> 
> adduser is neither essential nor required, thus does not need to be
> installed when installing postgres.  I'm not quite sure what you mean,
> could you please explain this?
> 
> Thanks in advance!

Hum, instead of adduser, useradd should be used by the posgresql
package. 
useradd is included in the package passwd, which is "required" package
from the "base" section.


 

-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

“漳州在线”特别公告

[漳州在线]

  “漳州在线”同城约会正在进行中


初秋了，已有些寒意，你是否正在期待这个秋季将要发生的浪漫爱情故事呢？你是否正在寻找那个能与你相知相守的他（她）呢？
 

“漳州在线”（http://zzren.cn)于10月15日开通了“交友”版块，在初秋的季节，你是否愿意加入我们热火朝天的同城约会呢？
 

在这里，我们可以悠闲地聊聊天，谈谈心灵深处曾有的感动，还可以相约去郊游或购物，这里所洋溢的温情与关怀将伴你走过愉快的秋冬季节。
 

朋友在的地方，孤单和寂寞只能躲在遥远的角落观望，这里的空气充满着快乐，你感受到了吗？
 

青春的日子，就应该尽情欢笑，尽情释放自己，让友情和爱情在这里快乐的飞扬吧！ 

你还在犹豫吗？别发呆了，快来加入我们吧！你没看到我们正张开双臂欢迎你吗？ 

漳州人自己的网站――漳州在线（http://zzren.cn)欢迎您！ 



  “漳州在线”特别公告


“漳州在线”人才版块已修复了部分问题，于10月15日全面通过测试，前段时间给大家造成的诸多不便，在此表示歉意。同时，也感谢大家的关心与支持，欢迎大家继续注册、使用，也请大家继续关注“漳州在线”的发展与更新。

应广大网友要求，“漳州在线”于10月15日开通了“交友”版块，属于我们的同城约会正在进行中。

Re: Pre-Depends for postgresql

[Colin Watson]

On Thu, Oct 16, 2003 at 03:51:33PM +0200, Mathieu Roy wrote:
> Martin Pitt <[EMAIL PROTECTED]> a tapoté :
> > adduser is neither essential nor required, thus does not need to be
> > installed when installing postgres.  I'm not quite sure what you mean,
> > could you please explain this?
> > 
> > Thanks in advance!
> 
> Hum, instead of adduser, useradd should be used by the posgresql
> package. 
> useradd is included in the package passwd, which is "required" package
> from the "base" section.

No, packages that need to add users or groups should use adduser so that
the appropriate uid and gid ranges are used as configured by the
sysadmin.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Pre-Depends for postgresql

[Andrew Suffield]

On Thu, Oct 16, 2003 at 03:51:33PM +0200, Mathieu Roy wrote:
> Hum, instead of adduser, useradd should be used by the posgresql
> package. 
> useradd is included in the package passwd, which is "required" package
> from the "base" section.

Please ignore this dangerous moron.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Pre-Depends for postgresql

[Mathieu Roy]

Colin Watson <[EMAIL PROTECTED]> a tapoté :

> On Thu, Oct 16, 2003 at 03:51:33PM +0200, Mathieu Roy wrote:
> > Martin Pitt <[EMAIL PROTECTED]> a tapoté :
> > > adduser is neither essential nor required, thus does not need to be
> > > installed when installing postgres.  I'm not quite sure what you mean,
> > > could you please explain this?
> > > 
> > > Thanks in advance!
> > 
> > Hum, instead of adduser, useradd should be used by the posgresql
> > package. 
> > useradd is included in the package passwd, which is "required" package
> > from the "base" section.
> 
> No, packages that need to add users or groups should use adduser so that
> the appropriate uid and gid ranges are used as configured by the
> sysadmin.

Even for system users automatically created by postinst scripts, on a
system where adduser has not even been already installed before?

(The postinst script may detect whether adduser is installed or not and
use useradd if adduser is missing.)



-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: Pre-Depends for postgresql

[Andreas Metzler]

Mathieu Roy <[EMAIL PROTECTED]> wrote:
> Martin Pitt <[EMAIL PROTECTED]> a tapoté :
>> On 2003-10-16 21:39 +1000, Russell Coker wrote:
>> > On Thu, 16 Oct 2003 19:00, Martin Pitt wrote:
>> > > The package postgresql needs to use 'adduser' and 'addgroup' in its
>> > > preinst script to properly save the current database before upgrading
>> > > (cf. Bug #180199). Therefore it should pre-depend on 'adduser'.

>>> Why would there be an issue on depending on a more important package?

>>> Having an optional/misc package pre-depend on an important/base
>>> package seems like a non-issue to me.
 
>> adduser is neither essential nor required, thus does not need to be
>> installed when installing postgres.  I'm not quite sure what you mean,
>> could you please explain this?

> Hum, instead of adduser, useradd should be used by the posgresql
> package. 
> useradd is included in the package passwd, which is "required" package
> from the "base" section.

IBTD. Apart from the fact that using adduser is explicitely recommended
in policy having _all_ packages use the same interface for
user-allocation IMHO is valuable on its own and outweighs getting rid
of a predependency.
   cu andreas

Re: Pre-Depends for postgresql

[Colin Watson]

On Thu, Oct 16, 2003 at 04:27:42PM +0200, Mathieu Roy wrote:
> Colin Watson <[EMAIL PROTECTED]> a tapoté :
> > On Thu, Oct 16, 2003 at 03:51:33PM +0200, Mathieu Roy wrote:
> > > Hum, instead of adduser, useradd should be used by the posgresql
> > > package. 
> > > useradd is included in the package passwd, which is "required" package
> > > from the "base" section.
> > 
> > No, packages that need to add users or groups should use adduser so that
> > the appropriate uid and gid ranges are used as configured by the
> > sysadmin.
> 
> Even for system users automatically created by postinst scripts, on a
> system where adduser has not even been already installed before?

Yes, especially for system users automatically created by postinst
scripts. This is important for consistency, which is why it's in policy
(9.2.2).

> (The postinst script may detect whether adduser is installed or not and
> use useradd if adduser is missing.)

Blech. We have dependencies and tools that install them automatically
for a reason.

(By the way, please don't cc me on replies; I read the list.)

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Pre-Depends for postgresql

[Mathieu Roy]

Colin Watson <[EMAIL PROTECTED]> a tapoté :

> On Thu, Oct 16, 2003 at 04:27:42PM +0200, Mathieu Roy wrote:
> > Colin Watson <[EMAIL PROTECTED]> a tapoté :
> > > On Thu, Oct 16, 2003 at 03:51:33PM +0200, Mathieu Roy wrote:
> > > > Hum, instead of adduser, useradd should be used by the posgresql
> > > > package. 
> > > > useradd is included in the package passwd, which is "required" package
> > > > from the "base" section.
> > > 
> > > No, packages that need to add users or groups should use adduser so that
> > > the appropriate uid and gid ranges are used as configured by the
> > > sysadmin.
> > 
> > Even for system users automatically created by postinst scripts, on a
> > system where adduser has not even been already installed before?
> 
> Yes, especially for system users automatically created by postinst
> scripts.

> This is important for consistency, which is why it's in policy
> (9.2.2).

So there's no reason to avoid that dependancy on adduser, even if it's
not clearly a required package (yes, that was the beginning of the
thread), because of the policy it's de facto a required package
(yes, that was my point).






-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ I'm including the debian-devel list in CC since I appreciate the
opinion of others developpers ]

James Troup <[EMAIL PROTECTED]> writes:

> This package is dubiously small enough as it is without being split
> into two.  There's no need to separate the 2k .el file into a separate
> package.  If depending on emacs bothers you, make it a suggests.

Yes, the packages is small *but* IMHO this should be splited in two
since the -el package can but not used. Other issue is the last
depends of emacsen and someone can doesn't like have an emacsen
installed in machine.

- -rw-r--r--1 otavio   otavio   4.1K Oct  4 16:58 
search-citeseer-el_0.1-1_all.deb
- -rw-r--r--1 otavio   otavio   2.9K Oct  4 16:58 
search-citeseer_0.1-1.diff.gz
- -rw-r--r--1 otavio   otavio610 Oct  4 16:58 
search-citeseer_0.1-1.dsc
- -rw-r--r--1 otavio   otavio   5.4K Oct  4 16:58 
search-citeseer_0.1-1_all.deb
- -rw-r--r--1 otavio   otavio   1.2K Oct  4 16:58 
search-citeseer_0.1-1_i386.changes
- -rw-r--r--1 otavio   otavio11K Oct  4 16:56 
search-citeseer_0.1.orig.tar.gz

I think the current package is ready for inclusion in Debian Project
and really like if you reconsider your decision. If we doesn't want
small packages in Debian, please include this in Debian Policy and
then I'll agree without asking but this is not the case.

Thanks in Advance,
Otavio

- -- 
  O T A V I OS A L V A D O R
- -
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
- -
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQE/jr5JLqiZQEml+FURAvjGAJ9FbITI7GzMxfTnUmouMSaqdBRNPgCaA9+C
QJY4l0fdmRS/lKn1tNhwf18=
=vmyL
-END PGP SIGNATURE-

Re: Pre-Depends for postgresql

[Russell Coker]

On Thu, 16 Oct 2003 23:01, Martin Pitt wrote:
> > Why would there be an issue on depending on a more important package?
> >
> > Having an optional/misc package pre-depend on an important/base package
> > seems like a non-issue to me.
>
> adduser is neither essential nor required, thus does not need to be
> installed when installing postgres.  I'm not quite sure what you mean,
> could you please explain this?

If you depend on a less important package then it would be an indication that 
one of the packages in question has the wrong priority and therefore a bug.

If you pre-depend on an equally important package then there may be issues 
related to circular-dependencies at some future time.

If you have a non-base package pre-depend on a base package then the base 
package can never depend on it (base packages must not depend on non-base 
packages).  If you have an "optional" package depend on a package that is 
"important" or "required" then again it would be a bug for any other package 
to have a dependency that results in a circle leading back to your package.

So no matter what happens if you have postgres keep it's current section and 
priority (I can't see postgres becoming a base part of Debian or being 
considered important in the Debian priority system) then any problem related 
to your pre-depends will be a fairly obvious and unambiguous bug in someone 
else's package.

I've recently learnt about some of these things the hard way...  ;)

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: APT: Errors when replacing syslog by syslog-ng

[Matt Zimmerman]

On Sun, Oct 12, 2003 at 04:54:07PM +0200, Frans Pop wrote:

> I just got the following messages replacing syslog by syslog-ng from dselect 
> (Woody).
> Should this be reported as a bug? Against which package (syslog, syslog-ng, 
> apt)?

Definitely not apt.

> The problems are:
> - - messages regarding klogd and anacron are incorrect as syslog-ng provides 
> system-log-daemon so dependencies are met

Since sysklogd and syslog-ng conflict, sysklogd must be removed before
syslog-ng can be installed, so there is a window where packages depending on
system-log-daemon are broken.  As you can see from the message, this
situation is being explicitly permitted in order to allow the upgrade to
complete.

> - - these messages are displayed twice

This seems harmless enough, but would be dpkg's fault.

> - - syslog-ng is started, then stopped and then started again, why?

Also pretty harmless, and syslog-ng's fault.

-- 
 - mdz

Re: 2.5 IPsec kernel patch: orphaning the grsecurity patch

[Matt Zimmerman]

On Wed, Oct 08, 2003 at 09:45:53PM +0200, martin f krafft wrote:

> It's amazing how problem solving here is equated with "actively
> waiting for problems to go away".
> 
> I wanted to improve Debian, but apparently there is no interest.
> Herbert gets to pollute the kernel-source all he wants because
> apparently noone gives a flying food.

People care more about some things than others.  Given a choice between
IPsec in Debian kernels by default and being able to apply grsecurity to
Debian kernel source, I'd take IPsec anyday.

-- 
 - mdz

Re: Quote: Debian and Democracy at Advocato.org

[Matt Zimmerman]

On Wed, Oct 08, 2003 at 04:25:17PM -0300, Daniel Ruoso wrote:

> 
> Debian and Democracy
> Posted 7 Oct 2003 by exa (Master)
   

Ha.  Hahahaa.  Ha, ha, ha...

-- 
 - mdz

Re: Debian should not modify the kernels!

[Matt Zimmerman]

On Fri, Oct 10, 2003 at 09:30:06PM +0200, martin f krafft wrote:

> also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2003.10.10.0223 +0200]:
> > ...and the freeswan patch is not in the Linux kernel (and as I understand
> > it, it never will be).
> 
> The IPsec patch is not in the 2.4 kernel either. I don't get your
> point.

It is in 2.5 and 2.6.  It is in Linux henceforth.  FreeSWAN, on top of its
other issues, is not, has never been, and never will be, part of the
official kernel.

Is that clearer?

-- 
 - mdz

Re: Which packages will hold up the release?

[Matt Zimmerman]

On Wed, Oct 08, 2003 at 10:04:38PM -0500, Steve Langasek wrote:

> Note that the testing scripts themselves do not examine Build-Depends
> today; such problems are only identified through manually filed RC bug
> reports.  Which is not to say that we shouldn't be tracking such
> problems -- just that they don't actually hold a package out of testing
> by default.

I would really like to know who I need to bribe in order to get this to
happen.  I do not have a useful development environment at this time due to
my living situation, so unfortunately I cannot apply myself to thisk task
directly.

It is critical that we be able to at least satisfy build-dependencies within
a release, as a step toward guaranteeing buildability of packages within a
release.  This is important for prompt security updates, license compliance
and other good things.

-- 
 - mdz

Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)

[Matt Zimmerman]

On Thu, Oct 02, 2003 at 07:43:37PM -0400, Nathanael Nerode wrote:

> Eventually I found aptitude's "Dselect" theme, which helped some.
> 
> I guess aptitude could be made the recommended default package manager,
> but I would hope that:
> 1.  Something more closely approximating the Dselect theme is used by
> default, so that dselect users don't get utterly lost.

I don't see any particular reason why aptitude should need to cater to
dselect users, considering that we still ship dselect (as essential, no
less), and dselect users are more than welcome to continue using it for as
long as it is maintained.

It is more important to provide something that does not cause _everyone
else_ to get utterly lost, and let dselect users use dselect.

> 2.  "Remove unused packages automatically" is (a) better described and
>   (b) off by default.

I've never had a problem, either with understanding or using this feature.

-- 
 - mdz

Re: Package verification and "/usr/bin/install" tool replacements

[Matt Zimmerman]

On Sat, Oct 04, 2003 at 04:39:49AM +1000, Kim Lester wrote:

> Some of the ideas I have implemented include a "pkg info" file in each 
> package
> containing the
>   pathname
>   uid, gid (numeric)
>   md5sum,
>   size (useful to humans)
>   mode
>   symlink target (for symlinks)
> 
> a pkgverify command can be run on an installed package and the contents 
> of this
> pkginfo file are used to ensure the pkg is installed correctly. The 
> tool can also optionally
> correct missing/broken dirs, symlinks  as well as uid, ,gid, mode info.

The problem that you will encounter is that a package can be correctly
installed, but without having the permissions on the filesystem match what
is in the .deb.  This is normal and to be expected.

One problem you will encounter is that of directory permissions/ownership.
Since multiple packages can contain the same directory with different
permissions, there is no authoritative source of "correct" information.

Another is that it is permitted (and indeed quite common) for packages to
change permissions and ownership in the postinst script.  In fact, this is
currently the _only_ way to change user/group ownership for a
dynamically-created user.  Adam Heath was talking about implementing a
better way to do this at the source package level, but as far as I know it
does not exist yet.

These issues would produce many false positives for any such system based on
Debian packages, and any attempts to auto-fix would very likely break
perfectly valid installations.

-- 
 - mdz

Re: How tightly should main be self-contained?

[Matt Zimmerman]

On Fri, Oct 03, 2003 at 09:40:27AM -0400, Simon Law wrote:

>   I would be glad to change it if there were a fair number of
> developers who think that suggesting contrib software is fine.

Suggesting contrib software is fine.

-- 
 - mdz

Re: Which packages will hold up the release?

[Matt Zimmerman]

On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote:

> /* 
> 
> You might ignore this comment...
> 
> Looking at the list of RC bugs the packages seems to fall in two
> categories. Packages I don't use and packages I don't feel comfortable
> in touching (glibc being an example of the latter).

Have you tried popbugs, in the debian-goodies package?  It aims to show you
RC bugs in packages that you use.

> And then depencies and build-depancies for these packages is needed
> too. Has anyone tried to make such list of packages we can't release
> without and made a list of RC-bugs in excatly those packages?

An approach like the above would produce an individualized list for each
developer, and the intersection of these lists would end up being something
like what you envision here.  So if everyone fixes bugs in packages they
use, the packages that they use don't get removed.

-- 
 - mdz

Re: Where are we now? (Was: Bits from the RM)

[Matt Zimmerman]

On Thu, Oct 02, 2003 at 03:13:23AM -0500, Chris Cheney wrote:

> I still need to get KDE 3.1.4 into sid and stablized. I hope for it to
> be ready to migrate into sarge by Oct 20 (including the 10 day wait
> time). From what Colin Watson mentioned to me earlier today there are
> some other packages that are holding KDE out as well so hopefully they
> are resolved by then.

Can you list these packages, as candidates for NMUs or shame?  Given some of
the changes in testing recently, it might not be unreasonable for KDE 3 to
be forced in at the expense of these packages.

-- 
 - mdz

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Steve Greenland]

On 16-Oct-03, 10:50 (CDT), Otavio Salvador <[EMAIL PROTECTED]> wrote: 
> [ I'm including the debian-devel list in CC since I appreciate the
> opinion of others developpers ]

Okay, since you ask:

> James Troup <[EMAIL PROTECTED]> writes:
> > This package is dubiously small enough as it is without being split
> > into two.  There's no need to separate the 2k .el file into a separate
> > package.  If depending on emacs bothers you, make it a suggests.

James is correct. Just put it all in one package. No one is obliged to
use the .el files. 

> Other issue is the last depends of emacsen and someone can doesn't
> like have an emacsen installed in machine.

What part of "If depending on emacs bothers you, make it a suggests." did
you not understand?

> If we doesn't want small packages in Debian, please include this in
> Debian Policy and then I'll agree without asking but this is not the
> case.

Not every good practice is in Policy. You're supposed to be able to
apply a little common sense as well. The objection is not to a small
package but pointless splitting of packages.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Andreas Metzler]

Otavio Salvador <[EMAIL PROTECTED]> wrote:
> [ I'm including the debian-devel list in CC since I appreciate the
> opinion of others developpers ]

> James Troup <[EMAIL PROTECTED]> writes:

>> This package is dubiously small enough as it is without being split
>> into two.  There's no need to separate the 2k .el file into a separate
>> package.  If depending on emacs bothers you, make it a suggests.

> Yes, the packages is small *but* IMHO this should be splited in two
> since the -el package can but not used. Other issue is the last
> depends of emacsen and someone can doesn't like have an emacsen
> installed in machine.
[...]

If that "bothers you, make it a suggests" instead of a depends.
What point am I missing?
  cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: Debian should not modify the kernels!

[martin f krafft]

also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2003.10.10.2333 +0200]:
> It is in 2.5 and 2.6.  It is in Linux henceforth.  FreeSWAN, on top of its
> other issues, is not, has never been, and never will be, part of the
> official kernel.
> 
> Is that clearer?

Doesn't explain why the IPsec patch should be distributed in 2.4 by
default. Come on, you just don't want to get my point...

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpbplRaTIGPR.pgp
Description: PGP signature

Re: 2.5 IPsec kernel patch: orphaning the grsecurity patch

[martin f krafft]

also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2003.10.11.0554 +0200]:
> People care more about some things than others.  Given a choice between
> IPsec in Debian kernels by default and being able to apply grsecurity to
> Debian kernel source, I'd take IPsec anyday.

Well, I would do it the other way. And if there was a patch for
IPsec just like there is for grsecurity, we could both have our
ways.

What's your problem with understanding that, Matt?

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgptsCnjUtSs9.pgp
Description: PGP signature

600元建个专业网站!

[中国智能建站网]

 http://www.567com.com 中国智能自助建站网
 
 建站优惠套餐 660 元起！！
 
 庆国庆，即日起至10月30日，可享受报价9折优惠！

 赠送：
 1、登陆320个国内著名搜索引擎！
 2、向800个相关商务网站提交供求信息！
 3、现款现货，中国互动营销网会员资格！

 另提供文件下载、网上购物等附加功能！

http://www.567com.com 中国智能自助建站网
 
 功能：

中国智能自助建站系统是一套功能强大的网站自助管理系统！使用本系统，不但可以创建普通企业、个人网站，还可以创建功能丰富的电子商务网站！五分钟学会做网站，三天速成建站高手！免费试用
 
・ 500多款精美的网页模版任意挑选 
・ 功能强大的在线网页编辑器，任意图文混排 
・ 简、繁、英三种语言版本，简繁自动转换 
・ 自由增加、修改、删除栏目；隐藏或加密栏目 
・ 
网站功能非常丰富，如：新闻文章、图文展示、在线表单、访客留言、文件下载、网上购物等；
 
 
 http://www.567com.com 中国智能自助建站网

 http://www.567com.com 中国智能自助建站网

Re: Where are we now? (Was: Bits from the RM)

[Colin Watson]

On Fri, Oct 10, 2003 at 02:07:38PM -0400, Matt Zimmerman wrote:
> On Thu, Oct 02, 2003 at 03:13:23AM -0500, Chris Cheney wrote:
> > I still need to get KDE 3.1.4 into sid and stablized. I hope for it to
> > be ready to migrate into sarge by Oct 20 (including the 10 day wait
> > time). From what Colin Watson mentioned to me earlier today there are
> > some other packages that are holding KDE out as well so hopefully they
> > are resolved by then.
> 
> Can you list these packages, as candidates for NMUs or shame?  Given
> some of the changes in testing recently, it might not be unreasonable
> for KDE 3 to be forced in at the expense of these packages.

kdebase isn't even working properly yet. An upload was supposed to
happen a week or so ago; it was delayed by some toolchain issues, I
think, but I thought those had been resolved. I don't think it's
remotely feasible to force in KDE 3 until that situation changes.

However, at least lm-sensors and i2c need attention soon. (I think most
of the other packages Chris mentioned that I was talking about are now
OK.)

-- 
Colin Watson  [EMAIL PROTECTED]

Debian Workshop in São Paulo - Brazil

[Eduardo Marcel Macan]

For the news: :)

The local Debian User Group in São Paulo is organizing a one-day
Debian Workshop to happen on Oct 25. The presentations were selected
by a group which reviewed the proposals collected after a Call 
For Papers was issued last month.

The english version of the press release is included in this mail,
further details on the speakers and their presentations is available
at http://www.debian-sp.org/oficina2003 , unfortunately, the details
are available only in Portuguese.

Regards!

Eduardo

   II Debian Workshop in São Paulo
   São Paulo - SP - Brazil
  10/25/2003


The Debian-BR[1] project  through the São Paulo State Debian User Group 
 - Debian-SP[2] and IBTA[3] (Brazilian Advanced Technologies Institute) 
invite you to the II Debian Workshop in São Paulo, on October 25, 2003.
The workshop consists of four presentations with hands-on demonstrations
of concepts, tutorials and practices using the Debian GNU/Linux
distribution.

The presentations will be of interest not only to Debian professionals 
or enthusiasts, but also to people who want to know more about the use 
and admnistration of free (as in speech) operating systems in general.

Schedule:
8:40h  - Welcome Coffee
9:00h  - Workshop:  Debian Kernel Maintainance 
 Speaker: Gustavo Noronha e Silva<[EMAIL PROTECTED]>

10:20h - Break

10:40h - Workshop: Software QoS, a cheap and effective way to
   control bandwidth on IP networks using Debian
   GNU/Linux
 Speaker:  Alessandro O. Ungaro <[EMAIL PROTECTED]>
12:00h - Lunch
14:00h - Workshop: Making Music with Debian GNU/Linux
 Speaker: Eduardo Marcel Maçan <[EMAIL PROTECTED]>
15:20h - Coffee Break
15:40h - Workshop: High Performance e-mail servers  
 Speaker: Michelle Ribeiro <[EMAIL PROTECTED]>
17:00h - Reserved for keysigning.
18:00h - End

Attendance is free of charge, but the number of participants is
restricted.
Reservations by phone +55-11-5081-9700

Address:
   IBTA - Instituto Brasileiro de Tecnologia Avançada
   Rua Vergueiro 1759 (next to Paraíso subway station)
   Vila Mariana - São Paulo - SP
   Tel: (11) 5081-9700
 
[1] http://www.debian-br.org
[2] http://sp.debian-br.org
[3] http://www.ibta.edu.br



-- 
"If you have an apple and I have  an apple and we  exchange apples then
you and I will still each have  one apple. But  if you have an idea and I
have an idea and we exchange these ideas, then each of us will have two
ideas." -- George Bernard Shaw  macan at debian dot org

Re: Bug#215103: ITP: gmasqdialer -- gtk/gnome client for masqdialer server

[Darren Salt]

I demand that David B Harris may or may not have written...

> On Mon, 13 Oct 2003 00:02:47 -0400
> Joe Drew <[EMAIL PROTECTED]> wrote:
>> David B Harris wrote:
>>> As much as you may dislike it, people care about toolkit. I don't
>>> understand the witch-hunt to remove references to such things.
>> Short description is a limited resource. By all means, put GTK or GNOME in
>> the long description if it is deemed necessary; apt searches will still
>> find what you're looking for.

> Obviously if the short description is too long, something needs to go - and
> in that case, certainly not mentioning the toolkit is reasonable. However,
> in this particular case ("gtk/gnome client for masqdialer server", but
> really "gnome client for masqdialer" since the "gtk" is assumed when
> talking about GNOME) is 35 characters long.

I think that GTK/GNOME is valid: a program may make use of GNOME features if
the relevant libraries are installed, but still work without them.

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| woody, sarge, | Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Oh, sarge too...

A misguided platypus will lay its eggs in your shorts.

Re: Debian should not modify the kernels!

[Matt Zimmerman]

On Thu, Oct 16, 2003 at 07:04:27PM +0200, martin f krafft wrote:

> also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2003.10.10.2333 +0200]:
> > It is in 2.5 and 2.6.  It is in Linux henceforth.  FreeSWAN, on top of
> > its other issues, is not, has never been, and never will be, part of the
> > official kernel.
> > 
> > Is that clearer?
> 
> Doesn't explain why the IPsec patch should be distributed in 2.4 by
> default. Come on, you just don't want to get my point...

It is the difference between a backport of a useful feature from a later
release, and an unofficial patch which was rejected upstream.  I think I
understand fine.

-- 
 - mdz

Re: 2.5 IPsec kernel patch: orphaning the grsecurity patch

[Matt Zimmerman]

On Thu, Oct 16, 2003 at 07:05:56PM +0200, martin f krafft wrote:

> also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2003.10.11.0554 +0200]:
> > People care more about some things than others.  Given a choice between
> > IPsec in Debian kernels by default and being able to apply grsecurity to
> > Debian kernel source, I'd take IPsec anyday.
> 
> Well, I would do it the other way. And if there was a patch for
> IPsec just like there is for grsecurity, we could both have our
> ways.

We still can; you just have to do a little work, either to port the patch
(apparently too difficult), or to revert the portions of the IPsec patch
which cause problems for grsecurity.

In exchange, everyone else gets IPsec by default, which, to me, is worth it.

-- 
 - mdz

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Otavio Salvador]

Steve Greenland <[EMAIL PROTECTED]> writes:

> On 16-Oct-03, 10:50 (CDT), Otavio Salvador <[EMAIL PROTECTED]> wrote: 
>> [ I'm including the debian-devel list in CC since I appreciate the
>> opinion of others developpers ]
>
> Okay, since you ask:

Perfect :-)

>> James Troup <[EMAIL PROTECTED]> writes:
>> > This package is dubiously small enough as it is without being split
>> > into two.  There's no need to separate the 2k .el file into a separate
>> > package.  If depending on emacs bothers you, make it a suggests.
>
> James is correct. Just put it all in one package. No one is obliged to
> use the .el files. 

And no one is obliged to do all like James think. The package follow
the policy and doesn't have any point in policy talking about size
requeriments.

>> Other issue is the last depends of emacsen and someone can doesn't
>> like have an emacsen installed in machine.
>
> What part of "If depending on emacs bothers you, make it a suggests." did
> you not understand?

Yes, I understand but is not right to me. Is really more logical split
it in two packages. If enduser need the emacs interface, only install
the -el.

>> If we doesn't want small packages in Debian, please include this in
>> Debian Policy and then I'll agree without asking but this is not the
>> case.
>
> Not every good practice is in Policy. You're supposed to be able to
> apply a little common sense as well. The objection is not to a small
> package but pointless splitting of packages.

Yes but to my sense is really better to enduser have this packages
splited since the search-citeseer can work (without problems) without
the -el part and I want provide this option for our users.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Otavio Salvador]

Andreas Metzler <[EMAIL PROTECTED]> writes:

> Otavio Salvador <[EMAIL PROTECTED]> wrote:
>> [ I'm including the debian-devel list in CC since I appreciate the
>> opinion of others developpers ]
>
>> James Troup <[EMAIL PROTECTED]> writes:
>
>>> This package is dubiously small enough as it is without being split
>>> into two.  There's no need to separate the 2k .el file into a separate
>>> package.  If depending on emacs bothers you, make it a suggests.
>
>> Yes, the packages is small *but* IMHO this should be splited in two
>> since the -el package can but not used. Other issue is the last
>> depends of emacsen and someone can doesn't like have an emacsen
>> installed in machine.
> [...]
>
> If that "bothers you, make it a suggests" instead of a depends.
> What point am I missing?

The opinion of James is not the same of my. I doesn't want to do all
thinks like he want but yes like the policy and major of users say.

The Social Contract say: The focus is the user. So, to enduser is more
easy provide two packages and he can choice what to do.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Joerg Jaspert]

Otavio Salvador <[EMAIL PROTECTED]> writes:

> And no one is obliged to do all like James think. The package follow
> the policy and doesn't have any point in policy talking about size
> requeriments.

Policy is not everything that counts. Just because policy doesnt say
something it means it is good to do it.

Its a useless split, not needed and there is no benefit for the users.
One can say its against users - everyone that wants .el files needs to
install another package. :)

> Yes but to my sense is really better to enduser have this packages
> splited since the search-citeseer can work (without problems) without
> the -el part and I want provide this option for our users.

"It can work without" is not enough for a split. One reason, but not
everything. If we would split everything that "works without the rest
in the package" we would end up with thousands of useless small
packages. We already have enough packages in the list, we dont need
things there we can avoid without problems.

-- 
bye Joerg
 if klecker.d.o died, I swear to god, I'm going to migrate to gentoo.


pgp3iOWpoz7cI.pgp
Description: PGP signature

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Peter Makholm]

Otavio Salvador <[EMAIL PROTECTED]> writes:

> The Social Contract say: The focus is the user. So, to enduser is more
> easy provide two packages and he can choice what to do.

I disagree. Forcing the user to spend to much time micromanage which
stuff he wants is not to the bennefit of the user. Neither for the
unexperienced user nor the power user.

It is bad practise to split packages just because it is posible to use
some parts of the package. 

-- 
 Peter Makholm | If you can't do any damage as root, are you still
 [EMAIL PROTECTED] |  really root?
 http://hacking.dk |   -- Derek Gladding about SELinux

Re: everyone deserves love, even you dsgdc

[Nina Hounsell]

Jump start your love life.

With millions of members, there's somebody for 
everyone - and that means you! 

Click below to join for free:


http://alwaysfeelgreat1.com/romance/







To update your list options: alwaysfeelgreat1.com/re/

"Do you think the company would be willing to lower my pay?" `With a torch.' 
Applicant interrupted interview to phone her therapist for advice on how to 
answer specific interview questions. `Yes,' said Arthur, `yes I did. It was on 
display in the bottom of a locked filing cabinet stuck in a disused lavatory 
with a sign on the door saying "Beware of The Leopard".'" 
ejtdvcijyyqvqsmaoxnxhgrxjnhopcpvlj

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Steve Greenland]

On 16-Oct-03, 13:11 (CDT), Otavio Salvador <[EMAIL PROTECTED]> wrote: 
> Yes but to my sense is really better to enduser have this packages
> splited since the search-citeseer can work (without problems) without
> the -el part and I want provide this option for our users.

My sense is exactly the opposite: people who don't use the -el will not
be inconvenienced by a few Kb of extra files, but those who want them
will have to go through extra effort to get them, after figuring out
why part of the upstream package is missing. And _everyone_ will have a
fractionally larger Packages file to download, and yet another package
item in whatever browser tool they use, cluttering searches.

And forget the "It's not in Policy" argument. Policy doesn't say "don't
put 'rm -rf /' in the postinst" either, but that doesn't make it a good
thing to do. Policy doesn't say "The minimum package size is N bytes",
because that doesn't make any sense - a package is as big as it needs to
be. Policy is intended to be a minimal document, the least that we need
to regulate to make a coherent integrated system. 

Glancing at a even few of the core packages should convince you that it
is not general practice to split upstream packages into the smallest
possible subsets. Everyone who has replied to your question (as of this
writing) has said it's a bad idea to split a package this small. If you
honestly wanted our opinions, this consistent response should be enough
to make you reconsider. If you were expecting a universal "Oh, that evil
James Troup, he's a power mad dictator" response, well, sorry, that's a
different thread, and a different topic.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: The sense of automake (Was: Processed: better make that 1.7.8... :-()

[Steve M. Robbins]

Just wanted to mention another approach that avoids guessing at which
files need to be touched and in what order.  This is what I use in
debian/rules when I need to modify automake source files:

# Suppress accidental execution of the auto-* tools; see
# http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg01416.html
#
no_auto_tools = ACLOCAL="`pwd`/missing aclocal" \
AUTOCONF="`pwd`/missing autoconf" \
AUTOMAKE="`pwd`/missing automake" \
AUTOHEADER="`pwd`/missing autoheader"

[...]

build-stamp:
[...]
$(MAKE) $(no_auto_tools)


Cheers,
-Steve

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Otavio Salvador]

Joerg Jaspert <[EMAIL PROTECTED]> writes:

> Otavio Salvador <[EMAIL PROTECTED]> writes:
>
>> And no one is obliged to do all like James think. The package follow
>> the policy and doesn't have any point in policy talking about size
>> requeriments.
>
> Policy is not everything that counts. Just because policy doesnt say
> something it means it is good to do it.

Of course but I think if the developper did something is because he
think this is better and this should be respected (if doesn't broke
the policy)

> Its a useless split, not needed and there is no benefit for the users.
> One can say its against users - everyone that wants .el files needs to
> install another package. :)
>
>> Yes but to my sense is really better to enduser have this packages
>> splited since the search-citeseer can work (without problems) without
>> the -el part and I want provide this option for our users.
>
> "It can work without" is not enough for a split. One reason, but not
> everything. If we would split everything that "works without the rest
> in the package" we would end up with thousands of useless small
> packages. We already have enough packages in the list, we dont need
> things there we can avoid without problems.

More or less. Doesn't make sense include a depends of Emacs in
search-citeseer and the -el part depends of this. The better option is
split in two package each with your depends and needs.

The sugestion of James is not right to include emacs like a suggets is
not good since the package need emacsen to work.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Otavio Salvador]

Peter Makholm <[EMAIL PROTECTED]> writes:

> Otavio Salvador <[EMAIL PROTECTED]> writes:
>
>> The Social Contract say: The focus is the user. So, to enduser is more
>> easy provide two packages and he can choice what to do.
>
> I disagree. Forcing the user to spend to much time micromanage which
> stuff he wants is not to the bennefit of the user. Neither for the
> unexperienced user nor the power user.

More or less. One search show both packages and user can read what
each do. Not so dificult ;-)

> It is bad practise to split packages just because it is posible to use
> some parts of the package. 

Of course. But one dependence like Emacs is. Many users doesn't want
emacs installed and they should be respected.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

anyone in nyc tomorrow for a keysigning?

[Andres Salomon]

I have the chance to tag along on a (company) trip to one of our colo
centers tomorrow (located at 25 Broadway, New York NY 10004-1010).  Are
any developers available tomorrow to sign keys in that general area? 
There don't appear to be any developers close to where I live (upstate
ny/albany area). 


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

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Peter Makholm]

Otavio Salvador <[EMAIL PROTECTED]> writes:

>> I disagree. Forcing the user to spend to much time micromanage which
>> stuff he wants is not to the bennefit of the user. Neither for the
>> unexperienced user nor the power user.
>
> More or less. One search show both packages and user can read what
> each do. Not so dificult ;-)

Not if you're the only one splitting packages unneccesary then it
doensn't matter. But you're not the only developer. Unneccessary
package splits isn't a problem if they only happends for a single
package but on a larger scale the means problems.

Micromanagement is bad!

>> It is bad practise to split packages just because it is posible to use
>> some parts of the package. 
>
> Of course. But one dependence like Emacs is. Many users doesn't want
> emacs installed and they should be respected.

And you still havn't told us what you didn't understand when James
wrote: 'If depending on emacs bothers you, make it a suggests.' They
*don't* have to have emacs installed!

-- 
 Peter Makholm |   Why does the entertainment industry wants us to
 [EMAIL PROTECTED] |  believe that a society base on full surveillance
 http://hacking.dk |   is bad?
   |   Do they have something to hide?

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Joerg Jaspert]

Otavio Salvador <[EMAIL PROTECTED]> writes:

> More or less. Doesn't make sense include a depends of Emacs in
> search-citeseer and the -el part depends of this. The better option is
> split in two package each with your depends and needs.

No.

> The sugestion of James is not right to include emacs like a suggets is
> not good since the package need emacsen to work.

For this package the suggest is enough. People that want to use the -el
files have emacs installed. Or they dont want to use the -el files. :)
The suggest is more like a reminder that there is something you can do
in emacs with this package imo.


-- 
bye Joerg
Das Ding heißt zwar Laptop, aber das sollte man so wörtlich nicht nehmen. Ein
50-jähriger schwedischer Wissenschaftler zog sich Verbrennungen an den
Geschlechtsteilen zu, weil er das Ding bei der Arbeit auf dem Schoß hielt.


pgp2N9CJ4yGYH.pgp
Description: PGP signature

Re: Pre-Depends for postgresql

[Martin Pitt]

Hi!

Please don't get me wrong, I don't insist of using adduser. IMHO
Mathieu's solution of checking whether adduser is available is
acceptable, if adduser is not installed then I can't break any admin
preferences anyway. In addition, user postgres has uid 31, thus
base-passwd should have given its blessings to postgres :-)

But I would like to understand this issue properly. Thus I am
bothering you again (sorry :-) ):

On 2003-10-17  2:14 +1000, Russell Coker wrote:
> If you depend on a less important package then it would be an indication that 
> one of the packages in question has the wrong priority and therefore a bug.

That's obvious.

> If you pre-depend on an equally important package then there may be issues 
> related to circular-dependencies at some future time.

I understand, but that doesn't hold here.

> If you have a non-base package pre-depend on a base package then the base 
> package can never depend on it (base packages must not depend on non-base 
> packages).  

That's basically the same as the first paragraph.

> If you have an "optional" package depend on a package that is
> "important" or "required" then again it would be a bug for any other
> package to have a dependency that results in a circle leading back
> to your package.

This confuses me. If a package can neither pre-depend on a package
that has a lower, an equal, nor a higher priority, then we wouldn't
need pre-dependencies at all. Could you convince an example?

> So no matter what happens if you have postgres keep it's current
> section and priority (I can't see postgres becoming a base part of
> Debian or being considered important in the Debian priority system)

Well, making a huge beast like postgres standard or even part of base
is certainly not desirable...

> then any problem related to your pre-depends will be a fairly
> obvious and unambiguous bug in someone else's package.

Could you explain this in more detail, please? Maybe with an example?

Currently, postgres is already using adduser in its preinst, but only
depends on it (which is kind of "too late"). The question is now,
should we make it officially pre-depend on it or should I convince
Oliver to rewrite the stuff to fall back to useradd (BTW: Oliver, do
you follow this?)

> I've recently learnt about some of these things the hard way...  ;)

I believe that and that's the reason why I want to understand this
thoroughly.

Thanks in advance for the time you spent to teach newbies! :-) The
policy only explains the purpose of pre-depends and I didn't find
anything in the Developer's Reference.

Have a nice day,

Martin
-- 
Martin Pitt
home:  www.piware.de
eMail: [EMAIL PROTECTED]

Re: Where are we now? (Was: Bits from the RM)

[Josip Rodin]

On Thu, Oct 16, 2003 at 06:09:10PM +0100, Colin Watson wrote:
> However, at least lm-sensors and i2c need attention soon.

The i2c bugs are due to some major upstream breakage. I don't see how we're
really going to handle that stuff, the situation is just plain old ugly.

(FWIW I still haven't (made|spent more time to figure out how to make) it
work with my TV card driver.)

-- 
 2. That which causes joy or happiness.

Re: Quote: Debian and Democracy at Advocato.org

[Matthew Palmer]

On Fri, Oct 10, 2003 at 06:27:59PM -0400, Matt Zimmerman wrote:
> On Wed, Oct 08, 2003 at 04:25:17PM -0300, Daniel Ruoso wrote:
> 
> > 
> > Debian and Democracy
> > Posted 7 Oct 2003 by exa (Master)
>
> 
> Ha.  Hahahaa.  Ha, ha, ha...

You don't think he's a Master?  I'm quite sure he's a Master debater.  He's
also probably a good fisherman - a baiter, as it were.

- Matt

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Matthew Palmer]

On Thu, Oct 16, 2003 at 05:32:11PM -0300, Otavio Salvador wrote:
> Joerg Jaspert <[EMAIL PROTECTED]> writes:
> 
> > Otavio Salvador <[EMAIL PROTECTED]> writes:
> >
> >> And no one is obliged to do all like James think. The package follow
> >> the policy and doesn't have any point in policy talking about size
> >> requeriments.
> >
> > Policy is not everything that counts. Just because policy doesnt say
> > something it means it is good to do it.
> 
> Of course but I think if the developper did something is because he
> think this is better and this should be respected (if doesn't broke
> the policy)

You've had about 8 people tell you that what you did was a bad idea, along
with some pretty reasoned arguments why.  (Make mine no. 9 - for all the
reasons already mentioned).

When public opinion comes out overwhelmingly against you, it's usually time
to think "hmm, I may be wrong there" rather than "everybody else is stupid".

> > "It can work without" is not enough for a split. One reason, but not
> > everything. If we would split everything that "works without the rest
> > in the package" we would end up with thousands of useless small
> > packages. We already have enough packages in the list, we dont need
> > things there we can avoid without problems.
> 
> More or less. Doesn't make sense include a depends of Emacs in
> search-citeseer and the -el part depends of this. The better option is
> split in two package each with your depends and needs.

Extending your argument just a bit, then there'd be a Debian package for
every binary, along with a bunch more for the collections of files all those
binaries need to work.  It Just Won't Scale.

> The sugestion of James is not right to include emacs like a suggets is
> not good since the package need emacsen to work.

And the only people who will give a crap about the -el working are those who
have emacs.  Presumably installed, so they won't notice that it needs emacs
to work.

I truly believe it's time to cut your losses, swallow your pride, and move
on.  Unless the lurkers support you in e-mail, of course.

- Matt

Norton AntiVirus failed to scan an attachment in a message you sent.

[10AntiVirus]

Recipient of the attachment:  SEXCHANGE, RADIANT\RII, 
StellaHsieh(謝立欣)/刪除的郵件
Subject of the message:  Re: That movie
No action was taken on the attachment.
  Attachment document_9446.pif was Logged Only for the following reasons:
Scan Engine Failure (0x80004005)

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Otavio Salvador]

Steve Greenland <[EMAIL PROTECTED]> writes:

> On 16-Oct-03, 13:11 (CDT), Otavio Salvador <[EMAIL PROTECTED]> wrote: 
>> Yes but to my sense is really better to enduser have this packages
>> splited since the search-citeseer can work (without problems) without
>> the -el part and I want provide this option for our users.
>
> My sense is exactly the opposite: people who don't use the -el will not
> be inconvenienced by a few Kb of extra files, but those who want them
> will have to go through extra effort to get them, after figuring out
> why part of the upstream package is missing. And _everyone_ will have a
> fractionally larger Packages file to download, and yet another package
> item in whatever browser tool they use, cluttering searches.

Yes. This way to show issues is the right one but the James way is
not. He doesn't do a suggestion but an exigency. This is wrong.

> And forget the "It's not in Policy" argument. Policy doesn't say "don't
> put 'rm -rf /' in the postinst" either, but that doesn't make it a good
> thing to do. Policy doesn't say "The minimum package size is N bytes",
> because that doesn't make any sense - a package is as big as it needs to
> be. Policy is intended to be a minimal document, the least that we need
> to regulate to make a coherent integrated system. 

Yes but policy also include what we have don't do.

> Glancing at a even few of the core packages should convince you that it
> is not general practice to split upstream packages into the smallest
> possible subsets. Everyone who has replied to your question (as of this
> writing) has said it's a bad idea to split a package this small. If you
> honestly wanted our opinions, this consistent response should be enough
> to make you reconsider. If you were expecting a universal "Oh, that evil
> James Troup, he's a power mad dictator" response, well, sorry, that's a
> different thread, and a different topic.

Yes. The reson of my first mail is exactly this. I want make some
troube to warn the way of some Debian Developpers do their work. James
have the better itention possible, to have small subset possible of
packages and like but the way of request it is wrong.

James should be more cordial and try talk with developpers. We
(developpers) are all tring to do a great distribution and we should
always discuss that things and doesn't thing we are always right.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Otavio Salvador]

Peter Makholm <[EMAIL PROTECTED]> writes:

> Otavio Salvador <[EMAIL PROTECTED]> writes:
>
>>> I disagree. Forcing the user to spend to much time micromanage which
>>> stuff he wants is not to the bennefit of the user. Neither for the
>>> unexperienced user nor the power user.
>>
>> More or less. One search show both packages and user can read what
>> each do. Not so dificult ;-)
>
> Not if you're the only one splitting packages unneccesary then it
> doensn't matter. But you're not the only developer. Unneccessary
> package splits isn't a problem if they only happends for a single
> package but on a larger scale the means problems.
>
> Micromanagement is bad!

Sure.

>>> It is bad practise to split packages just because it is posible to use
>>> some parts of the package. 
>>
>> Of course. But one dependence like Emacs is. Many users doesn't want
>> emacs installed and they should be respected.
>
> And you still havn't told us what you didn't understand when James
> wrote: 'If depending on emacs bothers you, make it a suggests.' They
> *don't* have to have emacs installed!

The way of James contact the developpers. He should be more cordial
and try explain that things not only reject a package and make
conditions to accept this.

I understand the cause and how James solve the problem but the thread
was more to try take attention on the way of things occour in
Debian. We should try be more cordial each other.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Otavio Salvador]

Matthew Palmer <[EMAIL PROTECTED]> writes:

>> Of course but I think if the developper did something is because he
>> think this is better and this should be respected (if doesn't broke
>> the policy)
>
> You've had about 8 people tell you that what you did was a bad idea, along
> with some pretty reasoned arguments why.  (Make mine no. 9 - for all the
> reasons already mentioned).
>
> When public opinion comes out overwhelmingly against you, it's usually time
> to think "hmm, I may be wrong there" rather than "everybody else is stupid".

Yes... I was wrong but my problem is with the way of ftp-master
conduct that things. This is the real problem.

>> The sugestion of James is not right to include emacs like a suggets is
>> not good since the package need emacsen to work.
>
> And the only people who will give a crap about the -el working are those who
> have emacs.  Presumably installed, so they won't notice that it needs emacs
> to work.
>
> I truly believe it's time to cut your losses, swallow your pride, and move
> on.  Unless the lurkers support you in e-mail, of course.

Yes.

This discussion was very useful to me learn some things and see some
others. But the focus of my problem was not the package reject but the
way ;-) Only it.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-

Re: Quote: Debian and Democracy at Advocato.org

[Brian Nelson]

Matthew Palmer <[EMAIL PROTECTED]> writes:

> On Fri, Oct 10, 2003 at 06:27:59PM -0400, Matt Zimmerman wrote:
>> On Wed, Oct 08, 2003 at 04:25:17PM -0300, Daniel Ruoso wrote:
>> 
>> > 
>> > Debian and Democracy
>> > Posted 7 Oct 2003 by exa (Master)
>>
>> 
>> Ha.  Hahahaa.  Ha, ha, ha...
>
> You don't think he's a Master?  I'm quite sure he's a Master debater.  He's
> also probably a good fisherman - a baiter, as it were.

"Like any of that's enough to fight the dark master bater.

I think you're drawing a lot of crazy conclusions about the unholy
prince bater."

-- 
I'm sick of being the guy who eats insects and gets the funny syphilis.


pgp6exA2MaIw6.pgp
Description: PGP signature

nethack popularity contest - number_pad?

[Joshua Kwan]

Searching for a general consensus here...

These days Debian's nethack packages contain default nethackrcs which
enable number_pad style controls (instead of hjkl keys) by default, due
to a bug filed on the packages a long time ago. Of course, there are some
who like it and some who don't. It's too trivial to ask a debconf question
about it upon install so it boils down to a popularity contest.

Which is better? I like the default keys because you learn how to use
nvi very efficiently knowing the hjkl-style keys :) I'm searching for as
many opinions as possible so please speak up!

Thanks,
-- 
Joshua Kwan


pgpvGOFKudAgR.pgp
Description: PGP signature

Re: Pre-Depends for postgresql

[Colin Watson]

On Thu, Oct 16, 2003 at 11:36:04PM +0200, Martin Pitt wrote:
> Please don't get me wrong, I don't insist of using adduser. IMHO
> Mathieu's solution of checking whether adduser is available is
> acceptable, if adduser is not installed then I can't break any admin
> preferences anyway. In addition, user postgres has uid 31, thus
> base-passwd should have given its blessings to postgres :-)

Uid 31 is reserved forever (speaking as the base-passwd maintainer), but
new installations of postgresql should have a uid in the system range,
namely 100-999, as created by 'adduser --system'. See the changelog for
base-passwd 3.5.0.

> Currently, postgres is already using adduser in its preinst, but only
> depends on it (which is kind of "too late"). The question is now,
> should we make it officially pre-depend on it or should I convince
> Oliver to rewrite the stuff to fall back to useradd (BTW: Oliver, do
> you follow this?)

No, you should definitely not attempt to fall back to useradd: that
whole subthread is just a distraction. Pre-depending on adduser is
perfectly fine and reasonable for a package like postgresql, and it is
wrong for a Debian package to try to use anything else other than
adduser to create system users. Using adduser means that we, or local
sysadmins, only have one thing to change if we need to change how system
users work.

Use adduser. It's your friend.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Peter S Galbraith]

Otavio Salvador <[EMAIL PROTECTED]> wrote:

> [ I'm including the debian-devel list in CC since I appreciate the
> opinion of others developpers ]
> 
> James Troup <[EMAIL PROTECTED]> writes:
> 
> > This package is dubiously small enough as it is without being split
> > into two.  There's no need to separate the 2k .el file into a separate
> > package.  If depending on emacs bothers you, make it a suggests.
> 
> Yes, the packages is small *but* IMHO this should be splited in two
> since the -el package can but not used. Other issue is the last
> depends of emacsen and someone can doesn't like have an emacsen
> installed in machine.
> 
> -rw-r--r--1 otavio   otavio   4.1K Oct  4 16:58 
> search-citeseer-el_0.1-1_all.deb

Are you byte-compiling this elisp?

AFAIK, you need to depend on emacs itself (and not emacs-common) if you
byte-compile it.  I _think_ stuff can break if you don't, but I'm vague
on why.  Search the debian-emacsen archives.  I split off a package
because of that issue a while back, but the seperate -el package is 62KB.

If the above is correct, then you may bundle your .el file with the main
package without depending on Emacs providing that you don't bye-compile
it.  If it's 4K, it's presumably a very small elisp file anyway.

Peter

Re: nethack popularity contest - number_pad?

[Thomas Thurman]

On Thu, Oct 16, 2003 at 06:30:26PM -0700, Joshua Kwan wrote:
> Which is better? I like the default keys because you learn how to use
> nvi very efficiently knowing the hjkl-style keys :) I'm searching for as
> many opinions as possible so please speak up!

number_pad is your friend. It's far easier to remember the keys.

T

Re: nethack popularity contest - number_pad?

[Leonardo Boiko]

I find difficult to play nethack using the default keys - not because of
the standard hjkl vi keys, but because I can't get used to the yubn diagonals.
And number_pad leaves k for kicking stuff :)

Anyway, I'd guess anyone playing nethack is geek enough to figure out
how to change the keys.
-- 
Leonardo Boiko
http://quarto128.homeunix.net:128

Re: nethack popularity contest - number_pad?

[Herbert Xu]

Joshua Kwan <[EMAIL PROTECTED]> wrote:
> 
> Which is better? I like the default keys because you learn how to use
> nvi very efficiently knowing the hjkl-style keys :) I'm searching for as
> many opinions as possible so please speak up!

Real men use hjkl.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: nethack popularity contest - number_pad?

[Steve Langasek]

On Thu, Oct 16, 2003 at 06:30:26PM -0700, Joshua Kwan wrote:
> Searching for a general consensus here...

> These days Debian's nethack packages contain default nethackrcs which
> enable number_pad style controls (instead of hjkl keys) by default, due
> to a bug filed on the packages a long time ago. Of course, there are some
> who like it and some who don't. It's too trivial to ask a debconf question
> about it upon install so it boils down to a popularity contest.

> Which is better? I like the default keys because you learn how to use
> nvi very efficiently knowing the hjkl-style keys :) I'm searching for as
> many opinions as possible so please speak up!

hjkl is the brainchild of the Global Qwerty Conspiracy.  Don't fall prey
to their evil machinations.


-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Generic init framework (was: Re: faster boot)

[Guillem Jover]

On Wed, Oct 15, 2003 at 11:12:26AM +0200, Erich Schubert wrote:
> If we want to introduce a new init system into debian, we should prepare
> a generic init framework (like many distributions already have in place)
> that allows for

> - silent/verbose boot and output redirection
> - fancy display of success/failure (for example with colors)

  - gettextized output support ?

> - bootsplash and boot-icons integration
> - needs, provides as in LSB suggested
> - status reporting (which services are running?)
> - disabling of services in a consistent way (some are disabled via
>   /etc/defaults/package, some expect you to edit the init.d script,
>   some suggest removing the links)
> - hooks for other init systems (for example i'd like the apache init.d 
>   script to be aware of my minit, and restart itself via minit)

regards,
guillem

Re: Pre-Depends for postgresql

[Russell Coker]

On Fri, 17 Oct 2003 07:36, Martin Pitt wrote:
> > If you have an "optional" package depend on a package that is
> > "important" or "required" then again it would be a bug for any other
> > package to have a dependency that results in a circle leading back
> > to your package.
>
> This confuses me. If a package can neither pre-depend on a package
> that has a lower, an equal, nor a higher priority, then we wouldn't
> need pre-dependencies at all. Could you convince an example?

I am saying that if you depend on more important packages, then the only way 
it breaks is if something else is broken.

EG if postgresql pre-depends on adduser and adduser pre-depends on postgresql 
then there would be a problem, but this would be an obvious bug in adduser 
and nothing that you would have to be concerned with as maintainer of 
postgresql.

Also if postgresql p-d on adduser, adduser p-d on libpam-pgsql (assuming there 
is such a package), and libpam-pgsql p-d on postgresql then there will be a 
problem.  But again it would not be a problem with postgresql, so while 
working on postgresql you don't have to be concerned with that risk.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: nethack popularity contest - number_pad?

[John Hasler]

Joshua Kwan writes:
> Which is better?

The default keys are fine with me, but it would be nice to not have the "@"
white when in a black on white xterm.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Joel Baker]

On Thu, Oct 16, 2003 at 08:48:03PM -0300, Otavio Salvador wrote:
> Peter Makholm <[EMAIL PROTECTED]> writes:
> > And you still havn't told us what you didn't understand when James
> > wrote: 'If depending on emacs bothers you, make it a suggests.' They
> > *don't* have to have emacs installed!
> 
> The way of James contact the developpers. He should be more cordial
> and try explain that things not only reject a package and make
> conditions to accept this.
> 
> I understand the cause and how James solve the problem but the thread
> was more to try take attention on the way of things occour in
> Debian. We should try be more cordial each other.

I'm hardly the sort likely to be first in line to defend Mr. Troup's
policies about various things - a causal search of the list archives should
make that abundantly clear - but I fail to see how he wasn't being quite
civil, polite, and reasonable about it.

For that matter, he and I have differed over things in some of my packages;
however, he does, in my experience, actually try to explain what the issue
is, and offer alternatives if there appear to be any.

Listing specific things that must be done before the package will be
accepted can, in some cases, sound much less polite - and more like an
ultimatum. Listing the reasons for the rejection, and a brief explanation
of why they're relevant, should really suffice to give you the opportunity
to say "I don't agree, here's why:" in an equally polite manner. He's
been known to change his mind, when presented with suitable evidence
or persuasive argument, but his job as ftpmaster is, in large part, to
do exactly what he did - reject package uploads that appear to have
significant problems, which can include poor packaging decisions.
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU NetBSD/i386 porter: :' :
 `. `'
   `-


pgpZVMT5Rjc1G.pgp
Description: PGP signature

Re: search-citeseer_0.1-1_i386.changes REJECTED

[Martin Michlmayr]

* Otavio Salvador <[EMAIL PROTECTED]> [2003-10-16 20:44]:
> Yes. This way to show issues is the right one but the James way is
> not. He doesn't do a suggestion but an exigency. This is wrong.

I've seen package being rejected with a reason plus a note saying
something like "but if you don't agree with me, please re-upload".
In your case, rejecting your package was the right thing; I don't see
much reason for any argument or discussion in this particular case,
since it's quite clear (as this thread has shown).

I'm glad that there are some people who control uploads; infact, I
wish they sometimes were stricter (*grumble about animals-games being
accepted which I raised an objection when the ITP was posted*).
-- 
Martin Michlmayr
[EMAIL PROTECTED]