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