Re: BTS version tracking

[Mike Hommey]

- Forwarded message from Mike Hommey <[EMAIL PROTECTED]> -

From: Mike Hommey <[EMAIL PROTECTED]>
Subject: Re: BTS version tracking
To: Colin Watson <[EMAIL PROTECTED]>, [EMAIL PROTECTED]

>>> I'm really dumb today, I managed to send that to a wrong address.
>>> Additionally, I also managed to re-close the wrong bug (see below).
>>> I should just stop debian work for today.

On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson <[EMAIL PROTECTED]> 
wrote:
> (...)
> The 'reopen' command takes an optional submitter argument, so it was
> difficult to get a version in here unambiguously. Instead, we've
> introduced a new 'found' command, which says "I've found the bug in this
> version of the package". You can use this whether the bug is open or
> closed; if the bug's closed and you give a version more recent than the
> last recorded fixed version, the bug will be considered open again.
> 
>   found 1234567 1.3-2
> 
> 'found' is now preferred to 'reopen' except when reopening bugs that
> were closed without a version (e.g. closed as invalid).
> 
> When you mail nn-done without Version:, i.e. the old way of closing
> bugs, the bug tracking system does approximately what it always did and
> records the bug as closed for all versions of the package containing it.
> Obviously, this loses the benefits of version tracking, and is now
> intended only for pseudopackages and for closing bugs that were never
> bugs to start with. It's still OK to use 'reopen' in the traditional way
> to reopen such bugs in a versionless way, although the 'found' control
> command without a version number works too.

I was wondering, what is the correct way to handle when you're stupid
and close the wrong bug in changelogs ? (like i did with #321876, when i
intended to close #321976)

Mike

PS: The recent changes to the BTS (version tracking, block
functionality...) really rock.

- End forwarded message -


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

README - confusing, irrelevant, redundant, useless

[W. Borgert]

Hi,

I have to start yet another discussion about our packaging
practise.  Did anyone ever take a look at our
/usr/share/doc//README{,.gz} files?  If the users have
difficulties with a package, we often reply "Why didn't you read
the README?  It's called README for a reason!"  However, the
README files are cluttered with confusing, irrelevant,
redundant, and useless stuff.  That way, we educate our users
not to ReadTheFineReadme.

Do you think, that this does any favour to our users?  E.g.

- "Debian packages of this software are currently available.
  It should be possible to run "apt-get install " and
  have a recent version installed."

  This is a Debian package, so what?

- "Please send bug reports, requests for features, etc. to
  ."

  Don't we ask our users to use our BTS primarily?

- "To build , please run: ./configure; make; make
  install."

  This is OK to have in the source, but not in the .deb.  Same
  goes for information about possible configuration options.
  OTOH, the configuration options actually used in the Debian
  package are seldomly documented :-(

- ...long history of who maintained the package when...

  This information - not really relevant to the user - is, of
  course, in the changelog as well.

- ...stuff about API usage in a library package...

  That does belong to the -dev package only, right?

- "Common options: --foo --bar --baz"

  According to our policy, the program has a manual page.  While
  it's not bad, to repeat the information in other formats, it
  does - IMHO - not make sense in a README.

- "Readme file for ."

  Really?

- "This program is..." - exact copy of the package description.

  This README is redundant.

- "$Id: ... $" (one line Id plus four lines of text)

  Maybe I become picky, but CVS/RCS ids are not relevant to the
  user, esp. if the remainder of the README is irrelevant, too.

- "The latest version of  can be obtained at ."

  As a Debian user, I expect to get packages the Debian way.
  It's nice to have the upstream website address, but according
  to our policy I can find it in the copyright file.

Package maintainers, please:

1. Do not include the upstream README in the binary package, if
   it's not really important to the user.

2. Just copy the 5..10% of relevant information into the
   README.Debian, if appropriate.

3. Don't invent a README file artificially, if you don't have
   to say anything.

4. File minor bugs about such README files.

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Bug#323043: ITP: libqdox-java -- High speed source parser for extracting from Java class/method definitions

[Trygve Laugstøl]

Package: wnpp
Severity: wishlist
Owner: "Trygve Laugstøl" <[EMAIL PROTECTED]>


* Package name: libqdox-java
  Version : 1.5
  Upstream Author : Aslak Hellesøy <[EMAIL PROTECTED]>
Joe Walnes <[EMAIL PROTECTED]>
Mike Royle <[EMAIL PROTECTED]>
Paul Hammant <[EMAIL PROTECTED]>
Mike Williams <[EMAIL PROTECTED]>
* URL : http://qdox.codehaus.org/
* License : ASL derivate
  Description : High speed source parser for extracting from Java 
class/method definitions

The parser skims the source files only looking for things of interest such as
class/interface definitions, import statements, JavaDoc and member
declarations. The parser ignores things such as actual method implementations
to avoid overhead (while in method blocks, curly brace counting suffices).
 
The end result of the parser is a very simple document model containing enough
information to be useful.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.6-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Bug#323046: ITP: libjline-java -- Java library for handling console input similar to GNU and BSD readline

[Trygve Laugstøl]

Package: wnpp
Severity: wishlist
Owner: "Trygve Laugstøl" <[EMAIL PROTECTED]>


* Package name: libjline-java
  Version : 0.9.1
  Upstream Author : Marc Prud'hommeaux <[EMAIL PROTECTED]>
* URL : http://jline.sourceforge.net
* License : BSD
  Description : Java library for handling console input similar to GNU and 
BSD readline

People familiar with the readline/editline capabilities for modern
shells (such as bash and tcsh) will find most of the command editing
features of JLine to be familiar.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.6-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Re: remove ruby1.6

[Steve Langasek]

Hi Akira,

On Fri, Aug 12, 2005 at 10:24:05PM +0900, akira yamada / やまだあきら wrote:
> Nico Golde wrote:
> > Do you have an idea how many of them are packaged with
> > 1.8 too?

> The following source packages generate binary packages
> for ruby1.6 only:

Thanks for this list.  It appears that the following packages can be removed
from testing/unstable with no ill effects, since they have no
reverse-dependencies outside of this set:

>   drb (*)
>   erb (*)
>   libmutexm-ruby (*)
>   libnet-acl-ruby (*)
>   libopenssl-ruby (*)
>   liboptparse-ruby (*)
>   ruby-eserver (*)
>   soap4r (*)
>   xmlrpc4r (*)
>   testunit (*)
>   webrick (*)

Is there any reason not to file for immediate removal of these packages?  If
not, could the maintainers please do this?


The next packages have other reverse-dependencies which prevent their
removal from testing; some of them are the applications that are listed at
the bottom, included in your original list of ruby1.6-only packages:

>   gnome-ruby

Used by tictactoe, rsjog, and mhc-utils; should be ported to gnome2-ruby, I
guess?

>   libiconv-ruby (*)

Needed by dnsdoctor and zonecheck, which presumably also need porting to
ruby1.8.

>   racc (*)

Needs rdtool and libtmail-ruby updated to be ruby1.8-only before it can be
removed from testing, but could be removed from unstable at any time.

>   libstrscan-ruby (*)

Used by aswiki.  The packages amrita and rdtool would also need to drop
their ruby1.6 support before this package could be removed from testing.

>   libyaml-ruby (*)

Needed by dnsdoctor, zonecheck, and sisu.

>   libzlib-ruby (*)

The libzip-ruby package needs to drop its ruby1.6 support before this
package could be removed from testing.  In addition, debpartial depends on
libzlib-ruby (>= 0.5.1-1); this package probably needs to be rebuilt to drop
this dependency?


Finally, there are the application packages, which would need to be ported
to ruby1.8 (or at least, updated to use ruby1.8 instead of ruby1.6):

>   aswiki
>   riece
>   rsjog
>   tdiary
>   tictactoe

> Riece (riece-google and riece-rdcc) depends on
> ruby1.6 or ruby1.8.

> I don't know about aswiki, rsjog, tdiary (tdiary-plugin)
> and tictactoe.  (I use tDiary on ruby1.8 and I have no problem.)

Have the maintainers of these packages been contacted directly about
switching to ruby1.8?
   
Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#323048: ITP: libjmock-java -- Java library for testing code with mock objects

[Trygve Laugstøl]

Package: wnpp
Severity: wishlist
Owner: "Trygve Laugstøl" <[EMAIL PROTECTED]>


* Package name: libjmock-java
  Version : 1.0.1
  Upstream Author : Steve Freeman <[EMAIL PROTECTED]>
Tim Mackinnon <[EMAIL PROTECTED]>
Nat Pryce <[EMAIL PROTECTED]>
Joe Walnes <[EMAIL PROTECTED]>
* URL : http://jmock.codehaus.org/
* License : BSD
  Description : Java library for testing code with mock objects

Mock objects help you design and test the interactions between the
objects in your programs.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.6-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Bug#323050: ITP: maven2 -- Software project management and comprehension tool

[Trygve Laugstøl]

Package: wnpp
Severity: wishlist
Owner: "Trygve Laugstøl" <[EMAIL PROTECTED]>


* Package name: maven2
  Version : 2.0beta1
  Upstream Author : Jason van Zyl <[EMAIL PROTECTED]>
Brett Porter <[EMAIL PROTECTED]>
Emmanuel Venisse <[EMAIL PROTECTED]>
John Casey <[EMAIL PROTECTED]>
Kenney Westerhof <[EMAIL PROTECTED]>
Trygve Laugstøl <[EMAIL PROTECTED]>   
* URL : http://maven.apache.org/maven2
* License : ASL
  Description : Software project management and comprehension tool

Based on the concept of a project object model (POM), Maven can manage a
project's build, reporting and documentation from a central piece of
information.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.6-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Re: remove ruby1.6

[Michael Ablassmeier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi,

On Sun, Aug 14, 2005 at 05:35:35AM -0700, Steve Langasek wrote:
> > I don't know about aswiki, rsjog, tdiary (tdiary-plugin)
> > and tictactoe.  (I use tDiary on ruby1.8 and I have no problem.)

tictactoe (0.8.1-2) has been uploaded yesterday and now uses
ruby1.8/libgtk2-ruby.

bye,
- michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC/z9dEFV7g4B8rCURAsz0AJ0aPFix82B7lhdtJ6uzAIxsPFFaZwCfYPsv
3Dz/1NqFDmuKGZgu+CDvXhI=
=6X/Y
-END PGP SIGNATURE-


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

Dogme05: Team Maintenance

[W. Borgert]

Hi,

as a conclusion of many discussions at DebConf5, I propose to
maintain all packages by teams.  A fine way to do this, is by
having a pkg- project at alioth.debian.org.  It is useful to
invite non-DDs, esp. upstream developers and people from Debian
derivatives to participate in such teams.

Assumptions:

I. The most important packages in Debian are maintained by
   teams.  The experience with that modus operandi is very good.

II. Team maintainance gives higher quality packages, as more
people look at the packaging details.

III. The responsiveness on bug reports is higher, as more people
 can react without having to NMU.  Adjustments between team
 members can slow down this, but this is just a matter of
 agreements inside the team.

IV. Less need to orphan packages, as most teams will not
collapse, if a single maintainer drops out.  Less work for
our lion-hearted QA team.

V. If not at least two maintainers can be found for a particular
   package, it is not worthwhile to have it in Debian, at least
   not in a release.  experimental is OK.

VI. The advantages of team maintenance outweigh the problem of
team maintenance overhead.

VII. Team maintainence helps us to collaborate with upstream
 and derivers.

VIII. Packages not maintained by teams are not to go into
  unstable/testing/stable.

IX. As alioth becomes even more important to Debian, we will
have to strengthen (HA-ing) this resource.

X. Teams shall meet online or in sauna.  They are allowed to do
   DDR or ballroom dancing.

[Dogme05 is, of course, a pun on Dogme95.]

Cheers,
-- 
Wolfgang Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: Dogme05: Team Maintenance

[martin f krafft]

also sprach W. Borgert <[EMAIL PROTECTED]> [2005.08.14.1615 +0200]:
> V. If not at least two maintainers can be found for a particular
>package, it is not worthwhile to have it in Debian, at least
>not in a release.  experimental is OK.

[...]

> VIII. Packages not maintained by teams are not to go into
>   unstable/testing/stable.

No, please.

I second your incentive, but I don't think it should be a guideline
or best-practice rather than a rule. There is *way* too much
overhead and I don't think it warrants the benefits in many/most
cases.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
micro$oft windoze is like an air-conditioner:
it breaks down if you open a window.


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

Re: Please notify your rdepends' maintainers if you break an interface

[Adrian von Bidder]

On Sunday 14 August 2005 02.40, Robert Collins wrote:

> On a related note, should we consider defining a convention similar to
> soname for dynamic languages like perl/python etc? I.e. for a python
> library 'foo', install the code as 'foo1', and have a dummy package
> 'foo' which has a __init__.py containing 'from foo1 import *' ?

While something like this might be a good idea, I feel that Debian shouldn't 
go ahead on this - better if such things were addressed as conventions 
upstream.

cheers
-- vbi

-- 
Today is Sweetmorn, the 7th day of Bureaucracy in the YOLD 3171


pgpcIjVq9fr5A.pgp
Description: PGP signature

Bug#323076: ITP: dealer -- bridge hand generator

[Christoph Berg]

Package: wnpp
Severity: wishlist
Owner: Christoph Berg <[EMAIL PROTECTED]>

* Package name: dealer
  Version : 0.20040530
  Upstream Authors: Hans van Staveren <[EMAIL PROTECTED]>
Henk Uijterwaal <[EMAIL PROTECTED]>
* URL : http://www.dombo.org/henk/dealer.html
* License : Public domain with some files GPLv2+
  Description : bridge hand generator

 This program generates bridge hands for partnerships bidding training or for
 generating statistics that can be used to design conventions, or win
 postmortems. Dealer has been used in many bridge publications.
 .
 http://www.dombo.org/henk/dealer.html


Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Bug#323076: ITP: dealer -- bridge hand generator

[Jesus Climent]

On Sun, Aug 14, 2005 at 06:09:57PM +0200, Christoph Berg wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Christoph Berg <[EMAIL PROTECTED]>
> 
> * Package name: dealer
>   Version : 0.20040530
>   Upstream Authors: Hans van Staveren <[EMAIL PROTECTED]>
> Henk Uijterwaal <[EMAIL PROTECTED]>
> * URL : http://www.dombo.org/henk/dealer.html
> * License : Public domain with some files GPLv2+
>   Description : bridge hand generator
> 
>  This program generates bridge hands for partnerships bidding training or for
>  generating statistics that can be used to design conventions, or win
>  postmortems. Dealer has been used in many bridge publications.
>  .
>  http://www.dombo.org/henk/dealer.html

Few points:

1. the name of the package might be a namespace polution, since it is too
generic.

2. after reading and re-reading both the description and the long description,
i have no clue whatsoever what the program is for. Hopefuly in the final
package it will be reworded...

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.12|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

Congratulations. You are still alive. Most people are so ungrateful to be
alive. But not you. Not anymore.
--John (Saw)


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

Re: Dogme05: Team Maintenance

[Joerg Jaspert]

On 10381 March 1977, W. Borgert wrote:

> as a conclusion of many discussions at DebConf5, I propose to
> maintain all packages by teams.

No, thanks.

> VI. The advantages of team maintenance outweigh the problem of
> team maintenance overhead.

Not everywhere, no.

> VII. Team maintainence helps us to collaborate with upstream
>  and derivers.

No, why? You can have good connections to them without team-stuff.

> VIII. Packages not maintained by teams are not to go into
>   unstable/testing/stable.

Nope, wrong way.

Team maintenance may be nice for many things, but to make it a
constraint is bad and works against it.

-- 
bye Joerg
 Aquariophile: welches debian/ welche xfree version?
 woody
 Xfree version 86


pgp5fZQB3Xj20.pgp
Description: PGP signature

Re: Bug#323076: ITP: dealer -- bridge hand generator

[Frans Pop]

On Sunday 14 August 2005 18:58, Jesus Climent wrote:
> 1. the name of the package might be a namespace polution, since it is
> too generic.

Possibly bridge-player would be a good alternative.

> 2. after reading and re-reading both the description and the long
> description, i have no clue whatsoever what the program is for.
> Hopefuly in the final package it will be reworded...

For someone who has played bridge, the short and long descriptions are 
perfectly OK :-)


pgpB0uVgPwbR4.pgp
Description: PGP signature

Re: README - confusing, irrelevant, redundant, useless

[Benjamin Seidenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

W. Borgert wrote:

> Hi,
>
> I have to start yet another discussion about our packaging
> practise. Did anyone ever take a look at our
> /usr/share/doc//README{,.gz} files? If the users have
> difficulties with a package, we often reply "Why didn't you read
> the README? It's called README for a reason!" However, the README
> files are cluttered with confusing, irrelevant, redundant, and
> useless stuff. That way, we educate our users not to
> ReadTheFineReadme.
>
> Do you think, that this does any favour to our users? E.g.
>
> - "Debian packages of this software are currently available. It
> should be possible to run "apt-get install " and have a
> recent version installed."
>
> This is a Debian package, so what?
>
> - "Please send bug reports, requests for features, etc. to
> ."
>
> Don't we ask our users to use our BTS primarily?
>
> - "To build , please run: ./configure; make; make
> install."
>
> This is OK to have in the source, but not in the .deb. Same goes
> for information about possible configuration options. OTOH, the
> configuration options actually used in the Debian package are
> seldomly documented :-(
>
> - ...long history of who maintained the package when...
>
> This information - not really relevant to the user - is, of course,
> in the changelog as well.
>
> - ...stuff about API usage in a library package...
>
> That does belong to the -dev package only, right?
>
> - "Common options: --foo --bar --baz"
>
> According to our policy, the program has a manual page. While it's
> not bad, to repeat the information in other formats, it does -
> IMHO - not make sense in a README.
>
> - "Readme file for ."
>
> Really?
>
> - "This program is..." - exact copy of the package description.
>
> This README is redundant.
>
> - "$Id: ... $" (one line Id plus four lines of text)
>
> Maybe I become picky, but CVS/RCS ids are not relevant to the user,
> esp. if the remainder of the README is irrelevant, too.
>
> - "The latest version of  can be obtained at  website>."
>
> As a Debian user, I expect to get packages the Debian way. It's
> nice to have the upstream website address, but according to our
> policy I can find it in the copyright file.
>
> Package maintainers, please:
>
> 1. Do not include the upstream README in the binary package, if
> it's not really important to the user.
>
> 2. Just copy the 5..10% of relevant information into the
> README.Debian, if appropriate.
>
> 3. Don't invent a README file artificially, if you don't have to
> say anything.
>
> 4. File minor bugs about such README files.
>
> Cheers,


While I agree the README can be confusing, I think we do a disservice
to our upstream by not including it. Some readers may be interested in
the people who brought them the software, or knowing upstream's email
or any of these items you mention. As for readme versus man page, I
find manpages are usually more of a reference about syntax while
readme's are closer to a tutorial on usage.

I think a better solution would be to duplicate all the important
information about the software into the README.Debian and train users
to read that soley. The original readme is still intact for those
users who care. In addition, I would like to see a standardazation on
whether to compress the README and similar files, I always end up
typing less /usr/share/doc/blah/README.Debian[.gz] using tab
completion and have to go back and correcting my command to use zless
because half are compressed and half aren't. I also agree with what
Branden said in his WTFM presentation at debconf.. a readme command to
display the readme's to the user would be a very nice tool.

Benjamin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC/3dtev9LOsNKpIQRAkmyAJ9EQMuQCpPOW5P6XtPdGps2sms1mgCgsgEz
eUaQF/vXKll2trd+dU0GXEA=
=/crF
-END PGP SIGNATURE-


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

Re: Dogme05: Team Maintenance

[Petter Reinholdtsen]

[W. Borgert]
> as a conclusion of many discussions at DebConf5, I propose to
> maintain all packages by teams.

I agree that it is good to maintain packages in teams, to make sure
the project is less vulnerable to single maintainers going on
vacation, becoming sick, being run over by a bus or other things that
tend to happen to people from time to time.  I really wish all the
base packages was maintained in teams, as these are vital for the
stability and progress of the debian distribution.

It might be a nice goal to get all packages maintained by teams, but
seeing that some people have problems with team work, I suspect it
will be hard to achieve.  I welcome co-maintainers for all of my
packages, and hope the rest of the debian developers maintaining
packages will do the same.


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

Re: Bug#323076: ITP: dealer -- bridge hand generator

[Frans Pop]

On Sunday 14 August 2005 19:11, Frans Pop wrote:
> On Sunday 14 August 2005 18:58, Jesus Climent wrote:
> > 1. the name of the package might be a namespace polution, since it is
> > too generic.
>
> Possibly bridge-player would be a good alternative.

Eh, bridge-dealer of course. Sorry.


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

Re: Bug#323076: ITP: dealer -- bridge hand generator

[Steinar H. Gunderson]

On Sun, Aug 14, 2005 at 07:11:43PM +0200, Frans Pop wrote:
>> 1. the name of the package might be a namespace polution, since it is
>> too generic.
> Possibly bridge-player would be a good alternative.

bridge-dealer, preferrably? It doesn't really play bridge...

>> 2. after reading and re-reading both the description and the long
>> description, i have no clue whatsoever what the program is for.
>> Hopefuly in the final package it will be reworded...
> For someone who has played bridge, the short and long descriptions are 
> perfectly OK :-)

Indeed. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Bug#323076: ITP: dealer -- bridge hand generator

[W. Borgert]

On Sun, Aug 14, 2005 at 06:58:40PM +0200, Jesus Climent wrote:
> On Sun, Aug 14, 2005 at 06:09:57PM +0200, Christoph Berg wrote:
> > * Package name: dealer
...
> >   Description : bridge hand generator
...
> 2. after reading and re-reading both the description and the long description,
> i have no clue whatsoever what the program is for. Hopefuly in the final
> package it will be reworded...

A "bridge" works on OSI layer 2 (data link layer), unlike a
router.  So it must be a dll network traffic "generator", you
have to manually ("hand") pay for ("dealer").

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Bug#322762: finding the rest..

[Frank Lichtenheld]

On Sat, Aug 13, 2005 at 09:25:05PM -0400, Joey Hess wrote:
> We have a good start at a list, to find the rest we need to:
> 
> - Check lintian for usr-doc symlink warnings. (Unfortunatly
>   lintain.debian.org is partially down right now.)

Should work correctly again.

http://lintian.debian.org/reports/Tpostinst-should-not-set-usr-doc-link.html

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: README - confusing, irrelevant, redundant, useless

[W. Borgert]

On Sun, Aug 14, 2005 at 12:55:11PM -0400, Benjamin Seidenberg wrote:
> While I agree the README can be confusing, I think we do a disservice
> to our upstream by not including it. Some readers may be interested in
> the people who brought them the software, or knowing upstream's email

/usr/share/doc//copyright, according to our policy?

> or any of these items you mention. As for readme versus man page, I

Don't you think that most of the examples I gave are utterly
irrelevant to about 100% of our users, including me and you?

> find manpages are usually more of a reference about syntax while
> readme's are closer to a tutorial on usage.

All my examples show, that a lot of READMEs do not contain
tutorials, but irrelevant information.  I did not say anything
against useful information or tutorials in README files.  I
personally would prefer a tutorial in a file named, hm, maybe
"tutorial"?

> I think a better solution would be to duplicate all the important
> information about the software into the README.Debian and train users
> to read that soley. The original readme is still intact for those
> users who care. In addition, I would like to see a standardazation on

The name of the file "README" suggests reading its content is
highly important to the user.  Sometimes it really is.  The huge
number of useless READMEs thwarts that.  I still think,
information irrelevant to the user should be removed from the
binary package.  If one really cares, apt-get source .

> whether to compress the README and similar files, I always end up
> typing less /usr/share/doc/blah/README.Debian[.gz] using tab
> completion and have to go back and correcting my command to use zless
> because half are compressed and half aren't. I also agree with what

Doesn't /bin/zless work for both?

> Branden said in his WTFM presentation at debconf.. a readme command to
> display the readme's to the user would be a very nice tool.

Yes.  Unfortunately, I arrived one day too late for the talk.
Otherwise, I would have criticised Branden for proposing hacking
*roff instead of using DocBook/XML refentries :-)

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: Dogme05: Team Maintenance

[Antti-Juhani Kaijanaho]

W. Borgert wrote:
> VIII. Packages not maintained by teams are not to go into
>   unstable/testing/stable.

Does this mean you are volunteering as a team member for all packages
that currently have only one maintainer?

-- 
Antti-Juhani


signature.asc
Description: OpenPGP digital signature

Re: Bug#323076: ITP: dealer -- bridge hand generator

[Christoph Berg]

Re: Jesus Climent in <[EMAIL PROTECTED]>
> > * Package name: dealer
> >   Version : 0.20040530
> >   Upstream Authors: Hans van Staveren <[EMAIL PROTECTED]>
> > Henk Uijterwaal <[EMAIL PROTECTED]>
> > * URL : http://www.dombo.org/henk/dealer.html
> > * License : Public domain with some files GPLv2+
> >   Description : bridge hand generator
> > 
> >  This program generates bridge hands for partnerships bidding training or 
> > for
> >  generating statistics that can be used to design conventions, or win
> >  postmortems. Dealer has been used in many bridge publications.
> >  .
> >  http://www.dombo.org/henk/dealer.html
> 
> Few points:
> 
> 1. the name of the package might be a namespace polution, since it is too
> generic.

Most texts cite "dealer" in conjunction with the first author's name,
but everyone how has dealed [:-)] with bridge programs knows the
program by that name.

Note that I'm already maintaining "deal" which serves the same
purpose, but isn't used as widely. And if one name is generic that's
probably the shorter "deal".

> 2. after reading and re-reading both the description and the long description,
> i have no clue whatsoever what the program is for. Hopefuly in the final
> package it will be reworded...

I'll include the botton line from the latex-bridge description:
"Bridge is an intellectually challenging card game for four players."

(Maybe ITPs should include the proposed section (games in this case)
to resolve confusions like these.)

Thanks for your suggestions.


Re: Frans Pop in <[EMAIL PROTECTED]>
> > 1. the name of the package might be a namespace polution, since it is
> > too generic.
> 
> Possibly bridge-player would be a good alternative.

I don't think cramming the short description into the package name
improves things.

> > 2. after reading and re-reading both the description and the long
> > description, i have no clue whatsoever what the program is for.
> > Hopefuly in the final package it will be reworded...
> 
> For someone who has played bridge, the short and long descriptions are 
> perfectly OK :-)

Thanks :-)

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Bug#323076: ITP: dealer -- bridge hand generator

[W. Borgert]

On Sun, Aug 14, 2005 at 07:51:47PM +0200, Christoph Berg wrote:
> (Maybe ITPs should include the proposed section (games in this case)
> to resolve confusions like these.)

Or better, as sections become obsolete, the proposed debtags.

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: Bug#323076: ITP: dealer -- bridge hand generator

[Jesus Climent]

On Sun, Aug 14, 2005 at 07:11:43PM +0200, Frans Pop wrote:
> 
> > 2. after reading and re-reading both the description and the long
> > description, i have no clue whatsoever what the program is for.
> > Hopefuly in the final package it will be reworded...
> 
> For someone who has played bridge, the short and long descriptions are 
> perfectly OK :-)

For someone who is a civil engineer and deals with bridge contruction, it made
little sense. Of course, I was biased.

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.12|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

Sometimes, the only way to catch and uncatchable woman is to offer her a 
wedding ring.
--Senior Ed Bloom (Big Fish)


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

Re: Sample

[Wichert Akkerman]

Hello,

This email address is no longer in use; please use [EMAIL PROTECTED]
instead.


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

Re: README - confusing, irrelevant, redundant, useless

[Jesus Climent]

On Sun, Aug 14, 2005 at 12:02:36PM +, W. Borgert wrote:
> 
> - "Readme file for ."
> 
>   Really?

Well, you want to know which package a README belongs to when you get a README
without any other information... right?

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.12|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

That's thirty minutes away. I'll be there in ten.
--Wolf (Pulp Fiction)


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

Re: README - confusing, irrelevant, redundant, useless

[W. Borgert]

On Sun, Aug 14, 2005 at 08:17:53PM +0200, Jesus Climent wrote:
> On Sun, Aug 14, 2005 at 12:02:36PM +, W. Borgert wrote:
> > - "Readme file for ."
> >
> >   Really?
>
> Well, you want to know which package a README belongs to when you get a README
> without any other information... right?

Nice, if you find the README under /lost+found/ (remember the
times before journalling?), but in all other cases, a user knows
their files.  Or do you suggest to tag all files in Debian with
such an information? :-)

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: README - confusing, irrelevant, redundant, useless

[John Hasler]

Perhaps the upstream README should be renamed 'README.upstream'?
-- 
John Hasler


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

Re: Dogme05: Team Maintenance

[Marco d'Itri]

On Aug 14, "W. Borgert" <[EMAIL PROTECTED]> wrote:

> as a conclusion of many discussions at DebConf5, I propose to
> maintain all packages by teams.  A fine way to do this, is by
"One size fits all" methods are a bad idea. Different packages and
different maintainers have different requirements.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: README - confusing, irrelevant, redundant, useless

[Kevin Buhr]

Benjamin Seidenberg <[EMAIL PROTECTED]> writes:
>
> I think a better solution would be to duplicate all the important
> information about the software into the README.Debian and train users
> to read that soley.

If I was king of the world (or at least of Debian), I would go the
more radical route of renaming all upstream READMEs (which, as
W. Borgert points out, are of highly variable quality and often the
*last* thing a new user should be reading) to README.upstream.gz and
mandating the inclusion of a README.gz file of reasonably standard
form using existing README.Debian files as a starting point.

At a minimum, the README.gz file should include a brief package
description, an overview of what's included in the package, a "quick
start" section explaining how one is expected to get started using the
package (or at least a pointer to the upstream's "quick start"
documentation), and possibly some maintainer's notes at the bottom
explaining any special compilation options or patches included in the
Debian version.

Of course, it should be Debian-centric, telling the user how to get
started with *this* package, not a freshly built upstream version.  If
I don't have to copy "foo.cf-EXAMPLE" from the build directory to
"/usr/local/etc/opt/share/bar/foo.cf" to use this package, it
shouldn't be mentioned.

Now, this is the role that README.Debian is usually trying to play,
but not all packages include it, and even when they do, sometimes the
file is just a Debian maintainer sending out mad props out to his
peeps ;) or, more realistically, *only* explaining how the Debian
package differs from the standard upstream package and not giving the
kind of "quick start" stuff I'm thinking about.

Really, I can't count the number of times I've downloaded a package
and then had to resort to searching for binaries and manpages listed
in its "/var/lib/dpkg/info/*.list" file to figure out how to use it.

-- 
Kevin Buhr <[EMAIL PROTECTED]>


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

Re: README - confusing, irrelevant, redundant, useless

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> their files.  Or do you suggest to tag all files in Debian with
> such an information? :-)

Open a man page.

Gruss
Bernd


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

Re: Dogme05: Team Maintenance

[W. Borgert]

On Sun, Aug 14, 2005 at 08:45:43PM +0200, Marco d'Itri wrote:
> On Aug 14, "W. Borgert" <[EMAIL PROTECTED]> wrote:
> > as a conclusion of many discussions at DebConf5, I propose to
> > maintain all packages by teams.  A fine way to do this, is by
> "One size fits all" methods are a bad idea. Different packages and
> different maintainers have different requirements.

You would have different teams still, so it's not "one size fits
all".

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: README - confusing, irrelevant, redundant, useless

[W. Borgert]

On Sun, Aug 14, 2005 at 10:10:42PM +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > their files.  Or do you suggest to tag all files in Debian with
> > such an information? :-)
>
> Open a man page.

Because it has a NAME section?  OK, you won :-)

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: Dogme05: Team Maintenance

[Adam Heath]

On Sun, 14 Aug 2005, W. Borgert wrote:

> [snip]
>
> IX. As alioth becomes even more important to Debian, we will
> have to strengthen (HA-ing) this resource.
>
> X. Teams shall meet online or in sauna.  They are allowed to do
>DDR or ballroom dancing.
>
> [Dogme05 is, of course, a pun on Dogme95.]

Haha, this gave me a good laugh for an email.  Altho, as far as jokes go, this
was rather poorly delivered.


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

Re: Dogme05: Team Maintenance

[John Hasler]

W. Borgert writes:
> as a conclusion of many discussions at DebConf5, I propose to maintain
> all packages by teams.

You would have a team maintain 'units'?  That's silly.
-- 
John Hasler


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

Re: Dogme05: Team Maintenance

[W. Borgert]

On Sun, Aug 14, 2005 at 03:52:55PM -0500, Adam Heath wrote:
> Haha, this gave me a good laugh for an email.  Altho, as far as jokes go, this
> was rather poorly delivered.

If I would make my living as an entertainer or comedian, I would
have to live on social security or be hungry :-( Sorry.

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: Dogme05: Team Maintenance

[W. Borgert]

On Sun, Aug 14, 2005 at 03:42:23PM -0500, John Hasler wrote:
> You would have a team maintain 'units'?  That's silly.

If the team maintains only the package 'units', yes.  If the
same team maintains multiple relating packages, it's different.
E.g. the Debian XML/SGML group maintains 22 packages.

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: Dogme05: Team Maintenance

[Petter Reinholdtsen]

[John Hasler]
> You would have a team maintain 'units'?  That's silly.

I guess it is equally silly as it is to maintain prebaseconfig in a
team.  The prebaseconfig package is very simple, and maintained by a
team together with a lot of other very simple packages.  It works
quite well to maintain small and simple packages in a team. :)


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

Re: Dogme05: Team Maintenance

[John Hasler]

I wrote:
> You would have a team maintain 'units'?  That's silly.

W. Borgert writes:
> If the team maintains only the package 'units', yes.  If the
> same team maintains multiple relating packages, it's different.

There are no packages related to units.
-- 
John Hasler


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

packages still setting /usr/doc link

[Joey Hess]

The following is a list by maintainer of the 497 packages that still
contain code in their postinst to create links in /usr/doc/. That's been
a bug since 2002, and most of these packages have probably not been
updated since then, since recompiling most of them with a current
debhelper will remove the link code.

Please fix your packages. Filing bugs on nearly 500 packages is
something I'd prefer not to do, but it might come to that. We've been
working on this transition for 5 or 6 years now, and it's about time to
finish it.

See bug #322762 for some more info.

Benjamin Hill (Mako) <[EMAIL PROTECTED]>
   aub

Stefan Hornburg (Racke) <[EMAIL PROTECTED]>
   interchange-doc

J.H.M. Dassen (Ray) <[EMAIL PROTECTED]>
   spellutils

Gaetano Paolone (bigpaul) <[EMAIL PROTECTED]>
   odontolinux
   textchk

Davide Puricelli (evo) <[EMAIL PROTECTED]>
   doc-linux-it
   linuxfacile

Tim Dijkstra (tdykstra) <[EMAIL PROTECTED]>
   digitaldj

Martin Albert <[EMAIL PROTECTED]>
   svgalib4libggi

Bradley Alexander <[EMAIL PROTECTED]>
   scandetd

Hakan Ardo <[EMAIL PROTECTED]>
   libcompface

Ben Armstrong <[EMAIL PROTECTED]>
   xletters
   xpilot-extra

Don Armstrong <[EMAIL PROTECTED]>
   libhtml-calendarmonth-perl

Richard Atterer <[EMAIL PROTECTED]>
   btyacc
   libwww-doc

Jeff Bailey <[EMAIL PROTECTED]>
   diffmon

Alan Bain <[EMAIL PROTECTED]>
   f2c
   ratfor

Alan Bain <[EMAIL PROTECTED]>
   nec
   rbootd

Mark Baker <[EMAIL PROTECTED]>
   chimera2
   exim-html
   exim-texinfo

Mark Baker <[EMAIL PROTECTED]>
   exim

Andras Bali <[EMAIL PROTECTED]>
   nettoe

Miros/law L. Baran <[EMAIL PROTECTED]>
   cookietool
   xenophilia

Jules Bean <[EMAIL PROTECTED]>
   iceconf

Bradley Bell <[EMAIL PROTECTED]>
   xrootconsole

Edward Betts <[EMAIL PROTECTED]>
   esh
   joystick

Bastian Blank <[EMAIL PROTECTED]>
   zope-loginmanager

Eduard Bloch <[EMAIL PROTECTED]>
   cfdisk-utf8

Ed Boraas <[EMAIL PROTECTED]>
   aime-doc

A. Maitland Bottoms <[EMAIL PROTECTED]>
   dart
   emwin
   rx320

Rune B. Broberg <[EMAIL PROTECTED]>
   tuxtype

Daniel Burrows <[EMAIL PROTECTED]>
   eboard-extras-pack1

Giacomo Catenazzi <[EMAIL PROTECTED]>
   apt-zip

Juan Cespedes <[EMAIL PROTECTED]>
   genromfs

Randolph Chung <[EMAIL PROTECTED]>
   xgdipc
   xless

Ashley Clark <[EMAIL PROTECTED]>
   bottlerocket
   java2html
   perl2html

David Coe <[EMAIL PROTECTED]>
   camediaplay
   smtp-refuser

Stephen Crowley <[EMAIL PROTECTED]>
   gtk-engines-thinice

Matthew Danish <[EMAIL PROTECTED]>
   apt-dpkg-ref
   printop
   sipp

Julien Danjou <[EMAIL PROTECTED]>
   webcamd

Debian Install System Team 
   boot-floppies

Scott M. Dier <[EMAIL PROTECTED]>
   xmeter

Jean-Francois Dive <[EMAIL PROTECTED]>
   libsnmp-mib-compiler-perl

Jean-Francois Dive <[EMAIL PROTECTED]>
   libdata-compare-perl
   libnet-ping-external-perl

Bernd Eckenfels <[EMAIL PROTECTED]>
   memstat
   mmv

Mark W. Eichin <[EMAIL PROTECTED]>
   lx-gdb
   lxtools

Oliver Elphick 
   pgmonitor

David Engel <[EMAIL PROTECTED]>
   ld.so

Florian Ernst <[EMAIL PROTECTED]>
   xboard

Anthony Fok <[EMAIL PROTECTED]>
   cbrowser
   hbf-cns40-1
   hbf-cns40-2
   hbf-cns40-3
   hbf-cns40-4
   hbf-cns40-5
   hbf-cns40-6
   hbf-cns40-7
   hbf-cns40-b5
   lexmark7000linux
   ttf-arphic-bkai00mp
   ttf-arphic-bsmi00lp
   ttf-arphic-gbsn00lp
   ttf-arphic-gkai00mp
   ttf2pt1-chinese
   xa+cv
   xfonts-cmex-big5p

Andreas Franzen <[EMAIL PROTECTED]>
   diploma
   pgapack
   wzip

Gordon Fraser <[EMAIL PROTECTED]>
   wmcalc

Gordon Fraser <[EMAIL PROTECTED]>
   wmcb

Turbo Fredriksson <[EMAIL PROTECTED]>
   libroxen-asis
   libroxen-calculator
   libroxen-cloakingdevice
   libroxen-columnify
   libroxen-deepleap
   libroxen-dirlist
   libroxen-discussit
   libroxen-errormessage
   libroxen-explaindir
   libroxen-faq
   libroxen-finder
   libroxen-flash2
   libroxen-footnote
   libroxen-graphicalcounter
   libroxen-guestbook
   libroxen-hubbethrottle
   libroxen-imho
   libroxen-jsredirect
   libroxen-layout
   libroxen-linkif
   libroxen-mail
   libroxen-mailform
   libroxen-meta
   libroxen-ntuserauth
   libroxen-outline
   libroxen-path
   libroxen-photoalbum
   libroxen-pop3
   libroxen-popdrop
   libroxen-presentit
   libroxen-pretoggle
   libroxen-programcache
   libroxen-randomfile
   libroxen-referrerdeny
   libroxen-remoteuser
   libroxen-roxpoll
   libroxen-safequote
   libroxen-secureinsert
   libroxen-sexybody
   libroxen-simplenews
   libroxen-sqlcounter
   libroxen-sqlextras
   libroxen-stripper
   libroxen-swarm
   libroxen-switch
   libroxen-telnetproxy
   libroxen-tex
   libroxen-thumbnail
   libroxen-thumbview
   libroxen-tokenfs
   libroxen-trimpath
   libroxen-watchdog
   libroxen-webmail
   libroxen-zopegw
   nagat
   radiusclient
   roxen-fonts-iso8859-1
   roxen-fonts-iso8859-2
   tcpquota

David Frey <[EMAIL PROTECTED]>
   spell

Wilmer van der Gaast <[EMAIL PROTECTED]>
   axel
   rotix

Peter S Galbraith <[EMAIL PROTECTED]>
   mh-book
   powstatd
   powstatd-crypt
   p

Re: Dogme05: Team Maintenance

[Steinar H. Gunderson]

On Sun, Aug 14, 2005 at 11:28:41PM +0200, Petter Reinholdtsen wrote:
> I guess it is equally silly as it is to maintain prebaseconfig in a
> team.  The prebaseconfig package is very simple, and maintained by a
> team together with a lot of other very simple packages.  It works
> quite well to maintain small and simple packages in a team. :)

Not all small and simple packages have logical relationships with lots of
other packages.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: Dogme05: Team Maintenance

[Ben Armstrong]

On Sun, 2005-08-14 at 14:15 +, W. Borgert wrote:
> as a conclusion of many discussions at DebConf5, I propose to
> maintain all packages by teams.

It's a nice ideal.

> It is useful to
> invite non-DDs, esp. upstream developers and people from Debian
> derivatives to participate in such teams.

I've tried that.  No luck yet.

> Assumptions:

No arguments against I through IV.

> V. If not at least two maintainers can be found for a particular
>package, it is not worthwhile to have it in Debian, at least
>not in a release.  experimental is OK.

Says who?  I maintain some packages like this.  Let's say I support 50
to 100 niche users for a given package, but I'm the only developer in
the user community who cares to maintain the package in Debian.  I
maintain the package well, and my users are happy.  I would not be at
all happy if my package were forced out of Debian because it's "not
worthwhile".  I think that would be a terrible injustice to my users.

> VI. The advantages of team maintenance outweigh the problem of
> team maintenance overhead.

In my case, there would be a team of one.  I could take a "build it and
they will come" approach, I suppose, but unless by creating the project
actually attracted other developers, the team maintenance overhead
(basically just startup costs) would outweigh the advantages.  Let's
just say I'm not overly optimistic about my prospects, given my failure
so far to attract another developer to co-maintain with me.  Upstream is
just too busy doing upstream work, and doesn't want to be bothered with
packaging, which I seem to do well enough without their help.

> VII. Team maintainence helps us to collaborate with upstream
>  and derivers.

I collaborate just fine with upstream.  However, this collaboration with
derviers sounds interesting.  I haven't yet spoken with any derivers
responsible for my packages.  That might be an overlooked source of help
for me.  Thanks for the reminder that they're out there.

> VIII. Packages not maintained by teams are not to go into
>   unstable/testing/stable.

Again: will a team of one, with a "help wanted" sign hanging on it
suffice?  I am ideologically supportive of team maintenance, but
pessimistic about the prospects of some useful packages ever having more
than one maintainer, because they serve a small subgroup of specialized
users within Debian.

> IX. As alioth becomes even more important to Debian, we will
> have to strengthen (HA-ing) this resource.

"HA-ing".  I'm sorry.  I don't know what you mean.

> X. Teams shall meet online or in sauna.  They are allowed to do
>DDR or ballroom dancing.

Works for me.

Ben


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

Re: packages still setting /usr/doc link

[Henning Makholm]

Scripsit Joey Hess <[EMAIL PROTECTED]>

> The following is a list by maintainer of the 497 packages that still
> contain code in their postinst to create links in /usr/doc/.

Some of these packages have been orphaned, but have not yet had their
maintainer fields switched to QA.

> That's been a bug since 2002,

Huh? The closest I can find in policy is a footnote reading:

| At this phase of the transition, we no longer require a symbolic
| link in /usr/doc/. At a later point, policy shall change to make the
| symbolic links a bug.

I agree that it *should* be a bug, but I cannot see that it officially
*has* been one for three years.

> Brian Mays <[EMAIL PROTECTED]>
>bibtool
>gnushogi
>netcdf
>netcdf-perl
>xruskb

For example, all of these packages are orphaned by QA, as Brian seems
to be MIA. I'm working on adopting bibtool, and the next upload will
remove the /usr/doc symlink (as the current package is not
debhelperized, and its handcrafted prerm script helpfully leaves the
symlink untouched when $1=upgrade :-/).  Some of the others are still
in O state rather than ITA.

-- 
Henning Makholm"We can hope that this serious deficiency will be
  remedied in the final version of BibTeX, 1.0, which is
expected to appear when the LaTeX 3.0 development is completed."


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

Re: README - confusing, irrelevant, redundant, useless

[Ben Armstrong]

On Sun, 2005-08-14 at 12:55 -0400, Benjamin Seidenberg wrote:
> While I agree the README can be confusing, I think we do a disservice
> to our upstream by not including it.

That's my gut feeling too.

> I think a better solution would be to duplicate all the important
> information about the software into the README.Debian and train users
> to read that soley.

Duplication should be avoided when possible.  It's a lot of work.  If
you want to cross-reference particular parts of upstream's README in
README.Debian, that's far preferable.

Why not just help improve upstream's README when you encounter poor
quality work?  That's what you'd do with code, wouldn't you?

> The original readme is still intact for those
> users who care.

I don't think upstream's original, untainted README should be considered
sacrosanct, any more than any source code file in the same package.  If
it can be improved, patch it.  Then send your patches upstream.  If they
reject your patches, work with them until you arrive at a consensus.  If
a consensus can't be reached, continue to ship your version.  If you're
worried about people being confused about "missing" material you've
excised, state up front what you've done to it.  The curious can always
obtain the "untainted" README from the source package.

Ben


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

Re: packages still setting /usr/doc link

[Nico Golde]

Hi,
* Joey Hess <[EMAIL PROTECTED]> [2005-08-15 00:49]:
> The following is a list by maintainer of the 497 packages that still
> contain code in their postinst to create links in /usr/doc/. That's been
> a bug since 2002, and most of these packages have probably not been
> updated since then, since recompiling most of them with a current
> debhelper will remove the link code.
> 
> Please fix your packages. Filing bugs on nearly 500 packages is
> something I'd prefer not to do, but it might come to that. We've been
> working on this transition for 5 or 6 years now, and it's about time to
> finish it.
> 
> See bug #322762 for some more info.
 
[...] 
> Bradley Alexander <[EMAIL PROTECTED]>
>scandetd

[...]
I checked scandetd, it seems that it reffers to a very old
version of the policy.. 3.1.1
Don't know if in the paths in this policy and the FHS were
different.
But it seems that the scandetd as some other bugs (including
an easy to fix FTBFS). Does someone know if Bradley Alexander
<[EMAIL PROTECTED]> is active? Otherwise I will provide an
NMU.
Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpWs7RpgN3eF.pgp
Description: PGP signature

Re: packages still setting /usr/doc link

[Nigel Jones]

On 15/08/05, Nico Golde <[EMAIL PROTECTED]> wrote:
> Hi,
> * Joey Hess <[EMAIL PROTECTED]> [2005-08-15 00:49]:
> > The following is a list by maintainer of the 497 packages that still
> > contain code in their postinst to create links in /usr/doc/. That's been
> > a bug since 2002, and most of these packages have probably not been
> > updated since then, since recompiling most of them with a current
> > debhelper will remove the link code.
> >
> > Please fix your packages. Filing bugs on nearly 500 packages is
> > something I'd prefer not to do, but it might come to that. We've been
> > working on this transition for 5 or 6 years now, and it's about time to
> > finish it.
> >
> > See bug #322762 for some more info.
> 
> [...]
> > Bradley Alexander <[EMAIL PROTECTED]>
> >scandetd
> 
> [...]
> I checked scandetd, it seems that it reffers to a very old
> version of the policy.. 3.1.1
> Don't know if in the paths in this policy and the FHS were
> different.
> But it seems that the scandetd as some other bugs (including
> an easy to fix FTBFS). Does someone know if Bradley Alexander
> <[EMAIL PROTECTED]> is active? Otherwise I will provide an
> NMU.
> Regards Nico

# 1625 days old (needed 10 days)
# Removal request by djpig
# Trying to remove package, not update it

(From packages.qa.debian.org)
> --
> Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
> http://www.ngolde.de | http://www.muttng.org | http://grml.org
> VIM has two modes - the one in which it beeps
> and the one in which it doesn't -- encrypted mail preferred
> 
> 
> 


-- 
N Jones
Proud Debian & FOSS User
Debian Maintainer of: html2ps, ipkungfu, dvorak7min & windowlab

Re: packages still setting /usr/doc link

[Joey Hess]

Henning Makholm wrote:
> > That's been a bug since 2002,
> 
> Huh? The closest I can find in policy is a footnote reading:
> 
> | At this phase of the transition, we no longer require a symbolic
> | link in /usr/doc/. At a later point, policy shall change to make the
> | symbolic links a bug.
> 
> I agree that it *should* be a bug, but I cannot see that it officially
> *has* been one for three years.

You're right. However, I think it's past time to change policy and make
it a bug. The orignal plans had that happening for the sarge release
actually.

-- 
see shy jo


signature.asc
Description: Digital signature

Key replacement request for [EMAIL PROTECTED]

[Junichi Uekawa]

Hi,

It seems like my mail is getting dropped somewhere 
for some reason.

I'm Cc'ing debian-devel so that I don't have to go and hunt for
this mail every month I decide to resend.

I've revoked my previous key; I need this key to enter Debian Keyring
in order to operate as a Debian Developer.



The following is a text signed by Kenshi Muto:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Debian developer Junichi Uekawa <[EMAIL PROTECTED]> has lost his
previous key CD3756F4 and he is now using his new key E81E55C1 
since 2005-5-22

pub   1024D/CD3756F4 2000-04-29 [revoked: 2005-05-16]
  Key fingerprint = 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4
uid  Junichi Uekawa <[EMAIL PROTECTED]>
uid  Junichi Uekawa <[EMAIL PROTECTED]>

pub   1024D/E81E55C1 2005-05-22
  Key fingerprint = 183A 70FC 4732 1B87 57A5  CE82 D837 7D4E E81E 55C1
uid  Junichi Uekawa <[EMAIL PROTECTED]>
uid  Junichi Uekawa <[EMAIL PROTECTED]>
sub   4096g/05BD93CD 2005-05-22
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iEYEARECAAYFAkKilxAACgkQQKW+7XLQPLHvPgCgoxYmvFhxhV0w31VMpd2fu3YZ
sC8Ani6l9e47osvayo5mRiK630VlLPVn
=kwbK
-END PGP SIGNATURE-


My key
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.1 (GNU/Linux)

mQGiBEKRD7kRBACC41XcH+co6JF6H1smsuNN6FWdYoSKh1oGFZUYLGLvLvCrhgMe
Vi1NyDXsfEDgqznI5h+PCDYMr3uVS9cJXftu1naSefFte/pwIBX/WFCCTzIIU4ar
BGeCtTF3gUZ66vkHhCYWPZGnG4W3rRNdNtn5O/EWUyqrFJtOt51WsDFL8wCgk03m
Gf4v+2EKQTp3T/M4BaLW13ED/inK/ePXUqMGNMaAhsZniIfP3UcUO446JvqQGzHS
pwRnzV9thF5CJGwsaNpWMDd23BGnOXwPDzWiqWcW5VDUDWhpZhvN+GI+s5jb/5Cw
oQkD9xKvVi6LdX8h9/d0whclK+/rMnc0+XHQFXggA32kcf2KgEJGBm5D7rHidKzr
UixBA/0WbtBjUJb85QI92VvFy9aEO5Ac7QkkhbpSFq081sPKsK2L3PjKcQ+rKbjI
J4429FkTeNhNE86TeAugQC6n+UWsnx53DsibgVC0pYcAoBNEuWhxOpnNVaxv47OV
p2vZbmFpKRVUBNtNSpU+6PCnmrekgA1hZ7Pra08KV4Xy5hVUBbQiSnVuaWNoaSBV
ZWthd2EgPGRhbmNlckBkZWJpYW4ub3JnPoheBBMRAgAeBQJCkQ+5AhsDBgsJCAcD
AgMVAgMDFgIBAh4BAheAAAoJENg3fU7oHlXB0VkAnRFNJDg8PqD89lw0+T5hqHJM
lcjLAKCS/gYCuYE10D1HBTP68zWx1krWuIhGBBARAgAGBQJCkROtAAoJEDBZv5LN
N1b0m+wAn1Uxb6nSDs1trgM2KQLtRPXj1VFwAJsHEC6ekPHxP4H2+WiAIsZjJS9Z
/IhGBBARAgAGBQJCkvS9AAoJECuoJgLCzoCZz9QAn39a14cHswLHKGRSrWUaYNk9
IUZsAJ0chUTbxK2c2PNSd6av0gW/8I9IjYhGBBARAgAGBQJCk+CcAAoJEAQeOa9x
1fQ62vcAnjw7HSmJUSXPwtBGBlAKp0/DHEk1AJ9kaheW693nrV2iJB1kLXJm0gLE
U4hGBBARAgAGBQJCoHZ7AAoJEH4vMO7sqU+o86EAoKtUWDaI3mo27myCFt8Ac7Sl
my5VAJ0Sf03et8JqGegh7NEiis1EeKoGL4hGBBARAgAGBQJCoR0JAAoJEEClvu1y
0Dyxr48AoMlJUFa3tyWEsvbTQkYHSPTYd8mPAKDVijTRGsfmvCj3orGk3sffBOUw
FohGBBARAgAGBQJCoSocAAoJEBcFOQ7mbJuw5QoAoJhnFb90CPTHnDC3anEIOoWq
OyuMAJ0Ri/T8chotTyIy+3MCnjn8hAfvhLQlSnVuaWNoaSBVZWthd2EgPGRhbmNl
ckBuZXRmb3J0LmdyLmpwPoheBBMRAgAeBQJCkRCsAhsDBgsJCAcDAgMVAgMDFgIB
Ah4BAheAAAoJENg3fU7oHlXBikYAnirtxGyfJTIqXHgKSnBaJAoBUd9yAJ4kjpgq
rNOwdxFi4dXfqDwTTU+9pYhGBBARAgAGBQJCkROqAAoJEDBZv5LNN1b0WssAoNUU
+P6RDmP5iSoUBHaEd7EqbZ7UAKC8FVgFdfUk5ip4ZiZuMarMMTAL6YhGBBARAgAG
BQJCkvS4AAoJECuoJgLCzoCZ53kAnA68eCwpd3+CSGchRF9f9h4znrjlAJ4qFl9/
RoHemZryThcLbAS5oCMiuYhGBBARAgAGBQJCk+CVAAoJEAQeOa9x1fQ6+MwAoJry
aauPEbljrs17o+SMnGEGKSTqAJwMkKej0RNCK4+4W6SW74D99SJNN4hGBBARAgAG
BQJCoHZ5AAoJEH4vMO7sqU+o8nMAmQEfTuyuld112wzJMSBKpVv033ikAJsEEjPX
RspA/ESmUjh016TQ66+xy4hGBBARAgAGBQJCoR0HAAoJEEClvu1y0DyxJaEAoIsA
c2M91X1KyaT8sMd/CW4DFcSnAJ95v1RqJcnnmOEO0d/TNWZLN2012YhGBBARAgAG
BQJCoSoYAAoJEBcFOQ7mbJuwR7UAn355xuyUj3gBNLF3SaUpbrQGR7ozAKCWK1ip
PVVuI4cGohOBpPBJn8DKtYhGBBARAgAGBQJCoSzJAAoJEEAd0HcEq4YXEa4AmwRD
ziuBsmbOaUHU5lnLv27gstlvAKCBU8S09HRFAo1dasmUuT6o+gdY+LkEDQRCkQ/8
EBAAmdf6AT0864+F1D5QdC1nuBhWGnfpP6RlbSFEkn1GvytsLiTPFiamiSSStvGz
uuLnMN0MCmcP+z5yrmTw2JDApYmI+Zuru54uPkRLczu+9H2cnd4C9eXZPTfgSgme
E4D0gEGi01NtPyBCImDmVyXwe5adRuEgsnOtsbr4ZOoW2M3kRIUZBRm5iQQruQJj
Gx7eDT+T2T4vwr/i3h+jtaJN4l0yG83wSzd7npqMll9CrgHf6ZOrDPDioS/kiAPP
+kq96nuk/Hzo80lPd1YvHGsmAc1OGAqkCJAF/a86ZJ711zysblaZvW3iiUS6vybQ
35EIWgKXe4EfY+N/NmyIG0atlkwhfg9VWqjOKOz1eFmEv1CTfuttqDyOOTXbtUHH
vcwbHJaBFPDRd1CSQh9eBzBIY5Pi+Ri0+a9PrHIr6KrbCGJaWavIpmyS22PhQDdr
5JI+m0wBSfB/41WpBr79QRM2z+Uq/v5AnlefxaOF+txggB/bv0e3+mBnTv498V1P
eaAjT/4iEt5P8lu9XRCzFgCUzN8MThuxR0glxSc5se7dXEMHsu0vU6hmh44/uSe3
dUrMFPAUELi3o4fTGiSJxp+ig0xo8crbzv2nll0mlKIi2xxPWqAvekN1XYEfLzLs
gknD8IH2Gfnil+wh89jfWjDKzWkxRpIn8aPQeFfth3I0jRMAAwUP/itnPzGp38b6
2qOg43QF5svL6aXduUCeSHShb2vf/DDhg9N575Jp3heOONNA63i6DDI1BbS3gD77
XzPcjYSAQ9ypsytLSe3skRLXd0ZWzNXv4PF+x9j8LswUCo7Q90ZiYqVJw9ytR/51
3NjJZa2RxhJkqJQ91cT9//QjEgVuQE02MESCtEmZOpZjuYMpzzb2mdbRwbfK0Arr
+0tMRH5Jzn5FB69kyurq2R698oUYc0Wz+D9f6F/7mbbTbJLC7+rQsvLitvgf3cfE
Jdfrrl35EWgiHckwAr15FKFrPNTvMTF23tq/hbkhks5iDv8WR1STqdtxH/JqLBfT
PpdXoFhwnSA+JZ2q/iTOAIrx8PIAfInAHi21ooMrZn/nffRVmSH7wR1eZywFtAM9
M2SZywTTZ2BkJnNGQvK692yBJswg33t3v1TWCX1KbGg5Z3Hj0Z6ce8fiOA78x7Et
PzzwqEa19mF439YEOfABX7CNaLpuIJSNbaRAHyhA2AA/mVEtWfh0RMwGzvUoryt1
CQ0Qe7Op5yLNbhJ/OfoxpbQ84dX8XQvqI8M89Xmzbfa7vXTBkyke37L5gbyPRV3Z
rFrjrk9nV6JTBNA07LsKAA5Z/h9vrsCaBptNaQ/8FWw4hfGWtLPuObmZzGk1e0XL
zw89UxGytMYC1joccEXePoTr3gQB0tnPiEkEGBEC

Re: README - confusing, irrelevant, redundant, useless

[Henning Makholm]

Scripsit Ben Armstrong <[EMAIL PROTECTED]>
> On Sun, 2005-08-14 at 12:55 -0400, Benjamin Seidenberg wrote:

>> While I agree the README can be confusing, I think we do a disservice
>> to our upstream by not including it.

> That's my gut feeling too.

I don't think we should base gut feelings solely based on a filename.
There is no real consensus in the free software community on what one
should find in a file called README, so it would seem to be a fallacy
to try to discuss README files in general.

Or rather: the bits of information that *are* consensus components of
README files are things that we already have other standard locations
for in Debian packages, such as the package description, copyright
file and dependency information. If upstream ships a README file with
just these bits, there is no reason to include it in the .deb.

On the other hand, it is not at all uncommon for upstream authors to
include *additional* information in README files that goes beyond the
"standard" metadata about the package. Most often this is things like
a description of the background for why the software exists and an
analysis of alternative solutions and/or the limits of the solution
implemented in the package itself. In cases where this background
information dominates the README file, I think it is reasonable to
ship the entire file verbatim in the .deb even if it *also* contains a
small amount if basic information that can be found elsewhere.

In other cases README files contain rudimentary descriptions of how to
use the software. This most often happens when the README is the
*only* documentation shipped from upstream. In this case it is better
to reformat the description as a man page -- and omit the README file
itself if it is then completely redundant.

In any case, I object to the notion that the name README signals "this
is important information" to the user. In the tarball world (as well
as in the .zip world of the DOS/Windows communities) a README is the
closest thing to a package description; many users know this and do
not expect to find vitally important information there. In the rare
cases where the file does contain important information, it might be
best to ship it under a _different_ name in the .deb, for example
/usr/share/doc/foo/IMPORTANT.

>> I think a better solution would be to duplicate all the important
>> information about the software into the README.Debian and train users
>> to read that soley.

> Duplication should be avoided when possible.  It's a lot of work.

In some cases it is best to programmatically _move_ information from
README to a more appropriate place in the .deb.

For example, the upstream tarball for autotrace has a rather
heterogenous README file that contains a bit of package description,
some license information, a portability summary, informal
"build-dependency" information, a short-short manpage summary, and a
minimal example program that uses libautotrace. The latter item is the
only one that is not redundant in the .deb, so I let debian/rules *cut
out* the example program and ship it as
/usr/share/doc/libautotrace-dev/examples/sample.c instead.

> Why not just help improve upstream's README when you encounter poor
> quality work?  That's what you'd do with code, wouldn't you?

Because there is no universal convention for what belongs to a README
file, and the upstream author has a right to have different ideas
about it than you. In particular, much information that would be
redundant in /usr/share/doc/foo/README.gz would nevertheless
*naturally* be part of the README in an upstream tarball. They have
different, though overlapping, roles.

> I don't think upstream's original, untainted README should be considered
> sacrosanct, any more than any source code file in the same package.

Agreed.

> If it can be improved, patch it.  Then send your patches upstream.

Not necessarily. The requirements for a README in a .deb package are
different from the ones for a README in a tarball.

-- 
Henning Makholm"They want to be natural, the anti-social
 little beasts. They just don't realize that
 everyone's good depends on everyone's cooperation."


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

Re: packages still setting /usr/doc link

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Please fix your packages. Filing bugs on nearly 500 packages is
> something I'd prefer not to do

Why  do you have filled bug reports, then? Only for my packages?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322813
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322749

I btw agree that we should fix policy, too.

Gruss
Bernd


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

Re: packages still setting /usr/doc link

[Henning Makholm]

Scripsit Joey Hess <[EMAIL PROTECTED]>
> Henning Makholm wrote:

>> I agree that it *should* be a bug, but I cannot see that it officially
>> *has* been one for three years.

> You're right. However, I think it's past time to change policy and make
> it a bug.

Agreed.

-- 
Henning Makholm   "And here we could talk about the Plato's Cave thing for a
while---the Veg-O-Matic of metaphors---it slices! it dices!"


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

Re: Bug#322909: ITP: empy -- A templating system for Python

[Anibal Monsalve Salazar]

On Sat, Aug 13, 2005 at 03:47:37PM +0200, Ana Guerrero wrote:
>Package: wnpp
>Owner: Ana Guerrero <[EMAIL PROTECTED]>
>Severity: wishlist
>
>
>* Package name: empy
>  Version : 3.3
>  Upstream Author : Erik Max Francis <[EMAIL PROTECTED]>
>* URL : http://www.alcyone.com/software/empy/
>* License : LGPL
>  Description : A templating system for Python
>
>EmPy is a system for embedding Python expressions and statements
>in template text; it takes an EmPy source file, processes it, and
>produces output.
>This is accomplished via expansions, which are special signals
>to the EmPy system and are set off by a special prefix (by default
>the at sign, '@').  EmPy can expand arbitrary Python expressions
>and statements in this way, as well as a variety of special forms.
>Textual data not explicitly delimited in this way is sent unaffected
>to the output, allowing Python to be used in effect as a markup
>language.
>Also supported are "hook" callbacks, recording and playback via
>diversions, and dynamic, chainable filters.
>The system is highly configurable via command line options and
>embedded commands.

This bug report looks good to me but the one at
http://bugs.debian.org/322909 looks incomplete.

I haven't seen it in [EMAIL PROTECTED] even though the URL above
reads:

  Report forwarded to debian-bugs-dist@lists.debian.org, :
  debian-devel@lists.debian.org, <[EMAIL PROTECTED]>, ana guerrero
  <[EMAIL PROTECTED]>

I'm missing something?

Anibal Monsalve Salazar
--
 .''`. Debian GNU/Linux
: :' : Free Operating System
`. `'  http://debian.org/
  `-   http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: Dogme05: Team Maintenance

[John Goerzen]

On Sun, Aug 14, 2005 at 02:15:43PM +, W. Borgert wrote:
> Hi,
> 
> as a conclusion of many discussions at DebConf5, I propose to
> maintain all packages by teams.  A fine way to do this, is by
> having a pkg- project at alioth.debian.org.  It is useful to
> invite non-DDs, esp. upstream developers and people from Debian
> derivatives to participate in such teams.

I think the goal is good, but the implementation is not.

Why not rather move towards a more BSD approach, where any developer
can commit changes to any package?  It would work around having the
awkwardness of finding members of a team, or alternately, having to
convince someone to let you join a particular team.

What's more, alioth takes a lot of time to work with.  I often do
development on machines that are not connected to the 'net at a given
time, and upload packages later.  I would have no problem hosting my
darcs repository on alioth, but I would have a problem having to go to
alioth every time I upload a new version, or every time I upload a new
package, or whatnot.  If it can be integrated in a sane fashion with
other parts of Debian, then fine.  Otherwise, if it costs me time, I
want nothing to do with it.  Time I spend mucking around on alioth is
time I'm not spending fixing bugs or adding features.

-- John


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

Re: Dogme05: Team Maintenance

[Marco d'Itri]

On Aug 15, John Goerzen <[EMAIL PROTECTED]> wrote:

> Why not rather move towards a more BSD approach, where any developer
> can commit changes to any package?  It would work around having the
Any developer can already "commit" changes to any package. The obvious
problem is that it is very hard to have everybody involved agree on
non-trivial changes.
But I think that encouraging NMUs (even mass-NMUs) for trivial changes
would be good.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#323148: ITP: mozilla-firefox-webdeveloper -- web developer extension for the Firefox web browser

[Michael Spang]

Package: wnpp
Severity: wishlist
Owner: Michael Spang <[EMAIL PROTECTED]>

* Package name: mozilla-firefox-webdeveloper
  Version : 0.9.3
  Upstream Author : Chris Pederick
* URL : http://chrispederick.com/work/
* License : GPL
  Description : web developer extension for the Firefox web browser

The Web Developer Firefox extension adds a toolbar with several
features aimed at web developers. It can disable various web features,
outline page elements, quickly validate a web page by linking to a
web-based validation service, add user CSS to any page, resize the
browser to an arbitrary size (for screen size testing), and more.


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

Bug#323149: ITP: gjlv -- java log viewer for GNOME

[Michael Spang]

Package: wnpp
Severity: wishlist
Owner: Michael Spang <[EMAIL PROTECTED]>

* Package name: gjlv
  Version : 1.0.4 
  Upstream Author : Bodo Pfelzer <[EMAIL PROTECTED]>
* URL : http://gjlv.sourceforge.net/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : java log viewer for GNOME

The Java Log Viewer for GNOME is a graphical viewer for Java's XML logs.
Logs can be read from files or can be read from a socket with appropriate
configuration. When reading from a socket, the list is updated as records
are received. Individual records are displayed in a GTK list, with further
detail available through the detail window.


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

Re: Dogme05: Team Maintenance

[Roberto C. Sanchez]

On Mon, Aug 15, 2005 at 05:08:00AM +0200, Marco d'Itri wrote:
> On Aug 15, John Goerzen <[EMAIL PROTECTED]> wrote:
> 
> > Why not rather move towards a more BSD approach, where any developer
> > can commit changes to any package?  It would work around having the
> Any developer can already "commit" changes to any package. The obvious
> problem is that it is very hard to have everybody involved agree on
> non-trivial changes.
> But I think that encouraging NMUs (even mass-NMUs) for trivial changes
> would be good.
> 

I tend to agree.  Personally, I keep all my packages under subversion.
While I would certainly welcome help if I started falling behind or
otherwise needed it, it would be rather disruptive if someone started
uploading updates to my packages without coordination.

Regardless of whether or not I agreed with the changes, there is a real
problem in the sense that my package under revision control is no longer
in sync with whatever is in the archive.  I know that NMUs also pose the
same problem, but one of the goals behind an NMU should be to upload the
*minimal* change that corrects the specific problem.  In such cases it
should not be too difficult to get back in sync.

There would either have to be a) some agreed upon central repository for
*all* packages, or b) coordination between the primary team or
maintainer.  Option b is essentially what we do now, just that the
coordination is typically done in the form of patches.  I.e., people
don't go around randomly uploading other people's packages.  Option a is
likely doomed to fail since revision control tool choices are like a
choice of text editor or religion.

-Roberto

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


pgpkKeLDwA2pP.pgp
Description: PGP signature

Re: Key replacement request for [EMAIL PROTECTED]

[Stig Sandbeck Mathisen]

Junichi Uekawa <[EMAIL PROTECTED]> writes:

> It seems like my mail is getting dropped somewhere for some reason.

It's likely hiding somewhere, along with other keyring related mail.
I've yet to see a reply to the mail I sent to keyring-maint 10 months
ago.

> I'm Cc'ing debian-devel so that I don't have to go and hunt for this
> mail every month I decide to resend.

debian-private might be a better place, I'm not sure.

-- 
Stig Sandbeck Mathisen


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

Re: Dogme05: Team Maintenance

[Adam Heath]

On Sun, 14 Aug 2005, Roberto C. Sanchez wrote:

> Regardless of whether or not I agreed with the changes, there is a real
> problem in the sense that my package under revision control is no longer
> in sync with whatever is in the archive.  I know that NMUs also pose the
> same problem, but one of the goals behind an NMU should be to upload the
> *minimal* change that corrects the specific problem.  In such cases it
> should not be too difficult to get back in sync.

Actually, this brings up an interesting point.

When a new source gets uploaded, it replaces the previous.  If several NMUs
occur, each one replaces the former.  So, when the real maintainer(s) wake up,
they can only see the most recent NMU that took place.

It'd be nice if NMUs source uploads were auto-archived.

Of course, this would be solved by the idea that people have thrown around:
checking every source upload into revision control.


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

Re: README - confusing, irrelevant, redundant, useless

[W. Borgert]

On Mon, Aug 15, 2005 at 02:18:39AM +0200, Henning Makholm wrote:
...a lot of wise things...

I have to agree.  So how to proceed?  File minor bugs against
README files, that contain predominantly useless information?

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: Dogme05: Team Maintenance

[W. Borgert]

On Sun, Aug 14, 2005 at 08:29:47PM -0300, Ben Armstrong wrote:
> Says who?  I maintain some packages like this.  Let's say I support 50
> to 100 niche users for a given package, but I'm the only developer in
> the user community who cares to maintain the package in Debian.  I
> maintain the package well, and my users are happy.  I would not be at
> all happy if my package were forced out of Debian because it's "not
> worthwhile".  I think that would be a terrible injustice to my users.

Some of the things under Dogme05 is certainly exaggeration.
Sorry, if people thought I want to propose enforcement of "team
maintenance policy".  However, team maintenance for all
essential and standard is worthwhile and not un-realistic.

> "HA-ing".  I'm sorry.  I don't know what you mean.

Sorry, we may have to many abbreviation based verbs already, so
I should not invent new ones: HA = high availability.

Cheers,
-- 
W. Borgert <[EMAIL PROTECTED]>, http://people.debian.org/~debacle/


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

Re: Dogme05: Team Maintenance

[Stig Sandbeck Mathisen]

"W. Borgert" <[EMAIL PROTECTED]> writes:

> Sorry, if people thought I want to propose enforcement of "team
> maintenance policy".  However, team maintenance for all essential
> and standard is worthwhile and not un-realistic.

It's a good idea to discuss it, unless it's been discussed to death
already.

-- 
Stig Sandbeck Mathisen


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