Quoting Justin B Rye (jbr@edlug.org.uk): > > Mostly because of the rewording, but I think that both have the same > > weight. "Please report" or "you should report" have, IMHO, the same > > level of urgency. > > I like the "should" version. You introduced a "please" to mark the > action that the user is being asked to make a decision about, which > is a common convention in templates. Having another "please" in the > same template might distract from that; saying "you should" turns it > into part of the factual background information (it's their duty as > well-behaved members of the community!) instead. So, I kept "our" version... > > This is something we discussed in former reviews. The standard for > > en_US is definitely double quotes for quoting and our reviews are > > standardized on en_US spelling and typography....even if the main > > reviewers are British (except /me of course)..:-) > > I'm happy to standardise things in either direction. I've never > seen any particular evidence that modern en_GB users as a whole > prefer singlequotes, especially when typing on keyboards with > perfectly good <"> keysyms that would otherwise go unused. > > A harder question is whether we'd "correct" UTF-8 curlyquotes. ...which is not the case here..:-) So, Guillem, based on that rationale, I'd prefer keeping the double quotes. > >> I'd prefer something like "this pakages becomes not useful", instead > >> of "useless", the latter seems pretty strong. :) > > > > OK. Would seem fair. Justin, is "becomes not useful" the right way to > > write it in English ? > > Try "this package will not be useful". Adopted. > > >>> Turn "file a bug" into "report a bug". > >> > >> Or "file a bug report"? > > > > My original intent was that "file a bug" is kind of jargonic. I think > > that "filing" something might also be hard to understand for someone > > not very savvy with usual jargon, but I might be wrong, here. > > "File a bug" is verging on jargon, but "file a bug report" and > "report a bug" seem equally good to me. "file a bug report" adopted as Guillem is more comfortable with it. > >> Please use '*'. I've always got the impression that was the most used > >> itemization style in Debian, the recent numbers posted on debian-devel > >> confirms that, and I'm guessing the Smith project in a way might have > >> slightly turned the balance on those numbers. > > > > I followed that discussion and I understand the argument. > > > > I would prefer an argument from a typographical reference here. > > > > I think that the best reference for this would be the Chicago Manual > > of Style. I suspect we might end up with asterisks, though. > > In printed publications of course the standard is to use genuine > U+2022 bullet points, not asterisks. If we're sticking to things > we've got on our keyboards, asterisks make sense since after all > they're the most "bulletlike" character we've got and aren't useful > for much else. But minuses and pluses work too. The point here is that Guillem is somewhat right about asterisks being more used (see -devel) but we "slowly" enforced minuses so reverting this might be kinda inconsistent. I'm balanced here: no solution is really good... I may have a very small peference for using asterisks as of now on the basis of current practice...and too bad for the already reviewed descriptions and templates..:-| > >>> We generally recommend dropping "NOTE:" stuff. > >> > >> Why? I don't have a strong feeling about it, but it seems to make it > >> easier to visually mark this kind of out-of-band dependency information. > > > > In general, the reasoning is that separating in a paragraph is enough > > for the notice to be visible and we do our best to discourage the use > > of all-capitals letters (yelling, etc.). That also goes with a general > > stance where texts should be as neutral as possible and avoid carrying > > "emotional" charge... > > What makes the kernel requirements "out-of-band" and the hardware > requirements "in-band"(?), anyway? > > The real problem is that everything you say in a package description > _could_ be preceded by a "NOTE" prefix. This one was already a > prime example of note proliferation, since there's three successive > paragraphs start with "Note", "Also note", "NOTE:"! OK. So I left the "NOTE" aside. New files attached.
Template: libglide3/no_card
Type: boolean
Default: false
_Description: Manually select driver for 3Dfx card?
No 3Dfx card that is supported by glide3 was found. This package
supports cards based on the following 3Dfx chipsets: Voodoo
Banshee, Voodoo 3, Voodoo 4, and Voodoo 5.
.
If the graphics card in this computer does not use one of these
chipsets, and you are not compiling programs against glide,
this package will not be useful.
.
If the graphics card is based on one of these chipsets, you
should file a bug report against this package, including the output from the
"lspci -vm" command.
.
Please choose whether you want to manually select the driver to use for now.
Template: libglide3/driver
Type: select
Choices: h3, h5
Default: ${default}
_Description: Driver for 3D acceleration:
Please select the driver you would like to use for 3D acceleration:
- h3: Voodoo Banshee and Voodoo 3;
- h5: Voodoo 4 and Voodoo 5.
Template: libglide3/card
Type: select
Choices: ${choices}
_Description: Card to use for 3D acceleration:
Multiple 3Dfx-based cards were detected based on one of the
following 3Dfx chipsets: Voodoo 2, Voodoo Banshee, Voodoo 3, Voodoo 4, and Voodoo 5.
.
Please select the card you would like to use for 3D acceleration.
Template: libglide3/error
Type: note
Description: ${e1}
${e2}
Template: libglide2/no_card
Type: boolean
Default: false
_Description: Manually select driver for 3Dfx card?
No 3Dfx card that is supported by glide2 was found. This package
supports cards based on the following 3Dfx chipsets: Voodoo 2,
Voodoo Banshee, and Voodoo 3.
.
If the graphics card in this computer does not use one of these
chipsets, and you are not compiling programs against glide,
this package will not be useful.
.
If the graphics card is based on one of these chipsets, you
should file a bug report against this package, including the output from the
"lspci -vm" command.
.
Please choose whether you want to manually select the driver to use for now.
Template: libglide2/driver
Type: select
Choices: cvg, h3
Default: ${default}
_Description: Driver for 3D acceleration:
Please select the driver you would like to use for 3D acceleration:
- cvg: Voodoo 2;
- h3 : Voodoo Banshee and Voodoo 3.
Template: libglide2/card
Type: select
Choices: ${choices}
_Description: Card to use for 3D acceleration:
Multiple 3Dfx-based cards were detected based on one of the
following 3Dfx chipsets: Voodoo 2, Voodoo Banshee, and Voodoo 3.
.
Please select the card you would like to use for 3D acceleration.
Template: libglide2/error
Type: note
Description: ${e1}
${e2}
Source: glide
Section: libs
Priority: optional
Build-Depends: dbs (>= 0.25), debhelper (>= 5), autoconf, automake,
libtool (>= 1.5), libx11-dev, libxext-dev, libxxf86dga-dev, libxxf86vm-dev
Build-Conflicts: automake1.4
Maintainer: Guillem Jover <guillem@debian.org>
Homepage: http://glide.sf.net/
Vcs-Browser: http://git.hadrons.org/?p=debian/pkgs/glide.git
Vcs-Git: git://git.hadrons.org/git/debian/pkgs/glide.git
Standards-Version: 3.7.3
Package: glide2-bin
Section: graphics
Architecture: i386
Depends: ${shlibs:Depends}
Suggests: device3dfx-module, device3dfx-source
Description: graphics library for 3Dfx Voodoo based cards - support programs
This is a support package which should be installed if you use a
card based on 3dfx Interactive, Inc's Voodoo chipsets.
Package: libglide2
Section: libs
Architecture: i386
Depends: ${shlibs:Depends}, ${misc:Depends}, pciutils
Recommends: glide2-bin
Suggests: device3dfx-module, device3dfx-source
Conflicts: libglide2
Description: graphics library for 3Dfx Voodoo based cards - shared libraries
This package allows you to use the 3D functions of cards based on
3dfx Interactive, Inc's Voodoo 2 chipsets. You should install it if
you use such a card.
.
This package is not useful with Voodoo Banshee, Voodoo 3,
Voodoo 4, or Voodoo 5 cards, and the original Voodoo Graphics chipset
is no longer supported.
.
You'll need the 3dfx kernel driver to use this library.
Package: libglide2-dev
Section: libdevel
Architecture: i386
Depends: libglide2
Provides: libglide-dev
Conflicts: llibglide-dev
Description: graphics library for 3Dfx Voodoo based cards - development files
This package contains the header files, example programs, and
documentation necessary to develop software using libglide2.
Package: libglide3
Section: libs
Architecture: i386 alpha ia64 amd64
Depends: ${shlibs:Depends}, ${misc:Depends}, pciutils
Provides: libglide3-alpha
Replaces: libglide3-alpha, libglide3-dev
Conflicts: libglide3, libglide3-alpha
Description: graphics library for 3Dfx Voodoo based cards - shared libraries
This package allows you to use the 3D functions of cards based on
3dfx Interactive, Inc's Voodoo Banshee, Voodoo 3, Voodoo 4, and
Voodoo 5 chipsets.
You should install it if you use such a card.
.
This package does not need 3dfx, as it uses DRI instead.
Package: libglide3-dev
Section: libdevel
Architecture: i386 alpha ia64 amd64
Depends: libglide3
Provides: libglide-dev, libglide3-alpha-dev
Replaces: libglide2-dev, libglide3-alpha-dev
Conflicts: libglide3-alpha-dev
Description: graphics library for 3Dfx Voodoo based cards - development files
This package contains the header files, example programs, and
documentation necessary to develop software using libglide3.
Attachment:
signature.asc
Description: Digital signature