Bug#747697: [RFR] templates://debian-security-support/{debian-security-support.templates}
Christoph Biedl wrote: Justin B Rye wrote... [...] CHECK-SUPPORT-STATUS(1) === NAME check-support-status - check installed packages for ended security support (Should that perhaps be reduced security support?) Remainder of an early development phase when there was only the ended check. So it should be rather check installed packages for ended or reduced security support. But | check-support-status - check installed packages for ended or reduced security support | 11+2+3+4+5+6+7+8+ this should fit into 80 characters if possible. I was thinking of reduced as a cover-term for ended or limited, but it doesn't really work. We could I suppose invert the implied return value of the check and say just: check-support-status - check installed packages for security support [...] So your proposal is OK, except the optional attribute is missing. I'd write: | * the rest (optional): details, and/or a URL for further information. Yes, I suppose that's the solution. BUGS (More of a wontfix LIMITATIONS, really) Yes, it's just BUGS is a well-established name for that section. Using mixed distribution like half-stable, half-testing is not supported. Mixed distributions (or perhaps a mixed distribution). I tend to something like | Installations with mixed distributions like half-stable, half-testing | are not supported. but should leave the last word to you. Yes, that's grammatical. Of course, it's the subtly odd Debian use of distribution to mean OS development branch, but it's decades too late to worry about that one. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747697: [RFR] templates://debian-security-support/{debian-security-support.templates}
Christoph Biedl wrote: Justin B Rye wrote... Talking about the regular security maintenance life cycle worked in the templates, but here it's not clear what life cycle you're talking about - it might be the software life cycle (from proof-of-concept to mature project to death-by-bitrot) of the packages. And besides, once we start setting things up to allow an oldstable-LTS with incomplete security coverage, surely that *is* the planned security maintenance life cycle? This *is* mostly about squeeze-lts actually. So for that one, the life cycle will end in spring 2016. Should we add the Debian word to the regular security maintenance life cycle to clarify? The trouble is, once this package becomes part of the standard security support system, the claim that maintaining security support is not feasible for the planned life cycle becomes confusing. Does that mean even after taking this package into account? Also, this use of life cycle to mean support period strikes me as an unhelpful piece of IT industry jargon. Saying that Windows XP has a ten year life cycle ought to imply that homes and businesses would be full of baby Windows XPs just now... Still, I don't know why I'm still talking about this when your amended version of my patch with restored Debian branding looks okay. [...] Upstream has no control here. It's the Debian security team who decides to end support, but of course upstream's moves have some influence on that. If such a decision is made, the team will also release a new version of debian-security-support with an updated list. The part that still hasn't been made absolutely explicit is: is there a security announcement for it, and does the new version of d-s-s go into security.debian.org? That would make sense, but if so you'd need to update https://www.debian.org/security/faq#policy;... -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747697: [RFR] templates://debian-security-support/{debian-security-support.templates}
Hi there,
going through these template checks is somehow similar to root canal
treatment: It's done with best intentions, it actually doesn't hurt
that much but still isn't a very pleasant experience. Trust me, I've
been through both. Having said that, part of the lame excuse why I
didn't get back to you earlier ...
I'll try to keep this short. Assume ACK to the things that I don't
answer neither here nor in another mail.
Justin B Rye wrote...
- The following packages found on your system are affected by this.
+ The following packages found on this system are affected by this:
.
${MESSAGE}
I gather this template text is echoed by runtime messages from
binaries in the package (since there's a messages.po with the same
grammar problem). Should I give you a patch for that too?
Please do so (it seems you've done already). The po/messages.po
catalog file and check-support-status.txt manpage should be part of
any translation.
- For some Debian packages, maintaining security support is not
+ For some packages, maintaining security support is not
Please keep the Debian word. This whole package is about how Debian
supports certain packages, and I'd like to avoid an erroneous
assumption this was something that is upstream-driven.
Talking about the regular security maintenance life cycle worked in
the templates, but here it's not clear what life cycle you're
talking about - it might be the software life cycle (from
proof-of-concept to mature project to death-by-bitrot) of the
packages. And besides, once we start setting things up to allow an
oldstable-LTS with incomplete security coverage, surely that *is* the
planned security maintenance life cycle?
This *is* mostly about squeeze-lts actually. So for that one, the life
cycle will end in spring 2016. Should we add the Debian word to the
regular security maintenance life cycle to clarify?
Do I understand that it does this by *containing lists* of packages
with such limits?
These lists are indeed part of the package.
Okay, so if LibreOffice (say) declares that the
version of their software in stable is now unsupported, how is that
information going to reach users who have debian-security-support
already installed (apart from via the security mailinglists they
should also be subscribed to, that is)?
Upstream has no control here. It's the Debian security team who
decides to end support, but of course upstream's moves have some
influence on that. If such a decision is made, the team will also
release a new version of debian-security-support with an updated
list.
I would have expected this
package to have a cron-job downloading new lists and comparing them to
dpkg -l output, or maybe to receive package updates via the security
repository and automatically check for alerts via an apt hook. But
instead it seems to be essentially manual - is that correct?
Ending security support before end of the regular Debian security
maintenance life cycle does not happen that often, in the past this
has been two or three times a year if I recall correctly.
Keep in mind several Debian installations have very limited network
access, so fetching everything from the net isn't always possible (and
that's why I'm in favour of Debian since enforcing such a policy is
possible here).
[ debian/control ]
+Description: security support coverage checker
+ For some packages, it is not feasible to maintain full security
+ support for all use cases through the full distribution release
+ cycle.
Again, more Debian here (using wdiff style):
+Description: {+Debian+} security support coverage checker
+ For some {+Debian+} packages, it is not feasible to maintain full security
Christoph
signature.asc
Description: Digital signature
Bug#747697: [RFR] templates://debian-security-support/{debian-security-support.templates}
Justin B Rye wrote... Christian PERRIER wrote: I gather this template text is echoed by runtime messages from binaries in the package (since there's a messages.po with the same grammar problem). Should I give you a patch for that too? Would be a good idea, yes. Same for the manpage. So thanks for catching a lot of typos and staff. Oh boy, I must have been blind. Are you OK if I upload an manpage before we're done with the rest? Let me know if this is to disruptive for the process? I may be doing this wrong, but I attach a message-phrasing patch for the Bash script itself (on the assumption that the .po file just gets generated from it). It is, using a tool from the gettext suite. And the check-support-status.txt file, which I gather is asciidoc source for the man page: It is. CHECK-SUPPORT-STATUS(1) === NAME check-support-status - check installed packages for ended security support (Should that perhaps be reduced security support?) Remainder of an early development phase when there was only the ended check. So it should be rather check installed packages for ended or reduced security support. But | check-support-status - check installed packages for ended or reduced security support | 11+2+3+4+5+6+7+8+ this should fit into 80 characters if possible. --semaphore /path/to/semaphore \ (Semaphore is a strange word to use for what appears to be a status database recording things that have already been reported, but I suspect it's already too late to change it.) Again, something that just stayed from the early days. Will think about it. Since this option exists mostly for the test cases and I cannot think why anybody else would want to use it ... it's not too late yet. * the rest: An optional text or URL with further information. Is that some optional text, or a URL with further information, or is it optionally, (nothing, or) some text with further information, or a URL with further information? I'm guessing: * the rest: details, and/or a URL for further information. (I don't see any reason to forbid having both, if it'll fit.) The rest is fully optional. It should be short so it fits, and by the way it's not translatable - that's why I prefer a URL. So your proposal is OK, except the optional attribute is missing. I'd write: | * the rest (optional): details, and/or a URL for further information. If no --list is provided, the script is run for both ended and limited support, using the lists shipped in the package. *--dpkg* 'COMMAND':: The command to execute instead of dpkg. Mostly for tests. + Note: This does not override the usage when called as dpkg --compare-versions. *--dpkg-query* 'COMAND':: COMMAND The command to execute instead of dpkg-query. Mostly for tests. Wait... if this is a separate item, what non-querying, non-comparing dpkg calls was it talking about in the previous section? (Goes and looks) Apparently, only the call to dpkg --version. That seems a bit futile. Wouldn't it be simpler to have a --dpkg-version option? There are two commands that need overloading for the test suite, dpkg and dpkg-version, but since dpkg --compare-versions should always work as expected ... to be honest, my enthusiasm to spend much time here is limited. Since again, I don't see why anybody else would use that option - but I just don't want to implement options without documentation. BUGS (More of a wontfix LIMITATIONS, really) Yes, it's just BUGS is a well-established name for that section. Using mixed distribution like half-stable, half-testing is not supported. Mixed distributions (or perhaps a mixed distribution). I tend to something like | Installations with mixed distributions like half-stable, half-testing | are not supported. but should leave the last word to you. [...] -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package Watch out for a follow-up, I've overeagerly killed one or two paragraphs that needed a comment. Christoph signature.asc Description: Digital signature
Bug#747697: [RFR] templates://debian-security-support/{debian-security-support.templates}
Quoting Christoph Biedl (debian.a...@manchmal.in-ulm.de): Justin B Rye wrote... Christian PERRIER wrote: I gather this template text is echoed by runtime messages from binaries in the package (since there's a messages.po with the same grammar problem). Should I give you a patch for that too? Would be a good idea, yes. Same for the manpage. So thanks for catching a lot of typos and staff. Oh boy, I must have been blind. Are you OK if I upload an manpage before we're done with the rest? Let me know if this is to disruptive for the process? As for the manpage, no it is not disruptive. Please feel free to do so. I'd prefer debconf templates and debian/control, particularly debconf templates to still follow the proposed process (where I'll be handling the templates l10n, including calls for translations), though. signature.asc Description: Digital signature
Bug#747697: [RFR] templates://debian-security-support/{debian-security-support.templates}
Please find, for review, the debconf templates and packages descriptions for
the debian-security-support source package.
This review will last from Saturday, May 17, 2014 to Tuesday, May 27, 2014.
Please send reviews as unified diffs (diff -u) against the original
files. Comments about your proposed changes will be appreciated.
Your review should be sent as an answer to this mail.
When appropriate, I will send intermediate requests for review, with
[RFRn] (n=2) as a subject tag.
When we will reach a consensus, I send a Last Chance For
Comments mail with [LCFC] as a subject tag.
Finally, a summary will be sent to the review bug report,
and a mail will be sent to this list with [BTS] as a subject tag.
Rationale:
--- debian-security-support.old/debian/debian-security-support.templates
2014-05-17 08:16:08.229777212 +0200
+++ debian-security-support/debian/debian-security-support.templates
2014-05-17 08:18:22.759776423 +0200
@@ -1,18 +1,20 @@
Template: debian-security-support/ended
Type: text
-_Description: Security support has ended for one or more packages
+#flag:translate!:4
+_Description: No more security support for one or more packages
Unfortunately, security support for some packages needed to be stopped
before the end of the regular security maintenance life cycle.
.
- The following packages found on your system are affected by this.
+ The following packages found on this system are affected by this:
.
${MESSAGE}
1) add a debconf flag to unmark the last paragraph for translation. It
is untranslatable anyway and this will avoid common translators' errors such
as translating the variable name..:-)
2) turn the synopsis into a title which is usually recommended for
such kind of templates.
3) unpersonnalize: we recommend to avoid using your system...
I wonder if that template could use the error type instead of
text. It has the advantage (see debconf-devel(5) that debconf makes
its best for the administrator to see it...including modified colors
in the curses-based interfaces.
Changes in the other template are similar.
--- debian-security-support.old/debian/control 2014-05-17 08:16:08.229777212
+0200
+++ debian-security-support/debian/control 2014-05-17 08:19:39.728871752
+0200
@@ -17,8 +17,8 @@
Depends: ${misc:Depends},
adduser,
gettext-base,
-Description: Identify installed packages with ended/limited security support
- For some Debian packages, maintaining security support is not
+Description: identify installed packages with ended/limited security support
+ For some packages, maintaining security support is not
feasible for the planned life cycle. For other packages, security
support is limited, it does not cover the full feature set.
.
Uncapitalize the synopsis.
Unbrand the package description which makes it more easily usable by
derivative distributions (that's debatable because of the package name
itself but it doesn't really hurt anyway)
--
Template: debian-security-support/ended
Type: text
#flag:translate!:4
_Description: No more security support for one or more packages
Unfortunately, security support for some packages needed to be stopped
before the end of the regular security maintenance life cycle.
.
The following packages found on this system are affected by this:
.
${MESSAGE}
Template: debian-security-support/limited
Type: text
#flag:translate!:4
_Description: Limited security support for one or more packages
Unfortunately, security support for some packages had to be limited.
.
The following packages found on this system are affected by this:
.
${MESSAGE}
--- debian-security-support.old/debian/debian-security-support.templates
2014-05-17 08:16:08.229777212 +0200
+++ debian-security-support/debian/debian-security-support.templates
2014-05-17 08:18:22.759776423 +0200
@@ -1,18 +1,20 @@
Template: debian-security-support/ended
Type: text
-_Description: Security support has ended for one or more packages
+#flag:translate!:4
+_Description: No more security support for one or more packages
Unfortunately, security support for some packages needed to be stopped
before the end of the regular security maintenance life cycle.
.
- The following packages found on your system are affected by this.
+ The following packages found on this system are affected by this:
.
${MESSAGE}
Template: debian-security-support/limited
Type: text
-_Description: Security support is limited for one or more packages
+#flag:translate!:4
+_Description: Limited security support for one or more packages
Unfortunately, security support for some packages had to be limited.
.
- The following packages found on your system are affected by this.
+ The following packages found on this system are affected by this:
.
${MESSAGE}
--- debian-security-support.old/debian/control 2014-05-17 08:16:08.229777212
+0200
+++ debian-security-support/debian/control 2014-05-17 08:19:39.728871752
+0200
@@ -17,8 +17,8 @@
Depends:
Bug#747697: [RFR] templates://debian-security-support/{debian-security-support.templates}
Christian PERRIER wrote:
Rationale:
--- debian-security-support.old/debian/debian-security-support.templates
2014-05-17 08:16:08.229777212 +0200
+++ debian-security-support/debian/debian-security-support.templates
2014-05-17 08:18:22.759776423 +0200
@@ -1,18 +1,20 @@
Template: debian-security-support/ended
Type: text
-_Description: Security support has ended for one or more packages
+#flag:translate!:4
+_Description: No more security support for one or more packages
This makes the warning messages for ended and limited support less
similar. That's not necessarily a bad thing, I suppose. I was thinking
translators might have less work to do if it's
_Description: Ended security support for one or more packages
Unfortunately, security support for some packages needed to be stopped
before the end of the regular security maintenance life cycle.
No, needed is simple past, which implies that the situation
described (i.e. the need for curtailed security support) has ended;
what we want here is present perfect (the has construction), which
implies that the situation described has continuing relevance.
Unfortunately, it has been necessary to end security support for some
packages before the end of the regular security maintenance life cycle.
Likewise in the other template:
Unfortunately, it has been necessary to limit security support for some
packages.
.
- The following packages found on your system are affected by this.
+ The following packages found on this system are affected by this:
.
${MESSAGE}
I gather this template text is echoed by runtime messages from
binaries in the package (since there's a messages.po with the same
grammar problem). Should I give you a patch for that too?
And the man page, if you like. I see for a start there's confusion
about whether it's check-support-status or check-supported-status.
Oh, and while I'm poking about outside the usual file list, I notice
kdelibs is listed twice in security-support-limited.
[...]
-Description: Identify installed packages with ended/limited security support
+Description: identify installed packages with ended/limited security support
Well, it's not a capitalised verb phrase any longer, but you haven't
managed to cram it into DevRef's preferred noun phrase format; that
would need something like
Description: identifier for installed packages with ended/limited security
support
Or maybe detector... but that's awkward. How about:
Description: security support coverage checker
- For some Debian packages, maintaining security support is not
+ For some packages, maintaining security support is not
feasible for the planned life cycle. For other packages, security
support is limited, it does not cover the full feature set.
Talking about the regular security maintenance life cycle worked in
the templates, but here it's not clear what life cycle you're
talking about - it might be the software life cycle (from
proof-of-concept to mature project to death-by-bitrot) of the
packages. And besides, once we start setting things up to allow an
oldstable-LTS with incomplete security coverage, surely that *is* the
planned security maintenance life cycle?
Then the second sentence has a comma splice, and it's not 100% clear
that the full feature set is talking about features of the software.
Unbrand the package description which makes it more easily usable by
derivative distributions (that's debatable because of the package name
itself but it doesn't really hurt anyway)
In fact that's a bit of a problem, since the cycle we're talking about
is the Debian release cycle. But maybe we can say:
For some packages, it is not feasible to maintain full security
support for all use cases through the full distribution release
cycle.
This (like my revised synopsis) loses the idea that ended and
limited support are treated as separate issues, but that's
introduced in the next paragraph anyway.
This package provides a program to identify installed packages
where support had to be ended prematurely or is limited, and alerts
the administrator in that case.
The same problem with simple-past had to.
This package provides a program to identify installed packages for
which support has had to be limited or prematurely ended, and to
alert the administrator.
Do I understand that it does this by *containing lists* of packages
with such limits? Okay, so if LibreOffice (say) declares that the
version of their software in stable is now unsupported, how is that
information going to reach users who have debian-security-support
already installed (apart from via the security mailinglists they
should also be subscribed to, that is)? I would have expected this
package to have a cron-job downloading new lists and comparing them to
dpkg -l output, or maybe to receive package updates via the security
repository and automatically check for alerts via an apt hook. But
instead
Bug#747697: [RFR] templates://debian-security-support/{debian-security-support.templates}
Quoting Justin B Rye (justin.byam@gmail.com):
No, needed is simple past, which implies that the situation
described (i.e. the need for curtailed security support) has ended;
what we want here is present perfect (the has construction), which
implies that the situation described has continuing relevance.
Nice catch !
- The following packages found on your system are affected by this.
+ The following packages found on this system are affected by this:
.
${MESSAGE}
I gather this template text is echoed by runtime messages from
binaries in the package (since there's a messages.po with the same
grammar problem). Should I give you a patch for that too?
Would be a good idea, yes. Same for the manpage.
-Description: Identify installed packages with ended/limited security
support
+Description: identify installed packages with ended/limited security
support
Well, it's not a capitalised verb phrase any longer, but you haven't
managed to cram it into DevRef's preferred noun phrase format; that
would need something like
Description: identifier for installed packages with ended/limited security
support
Or maybe detector... but that's awkward. How about:
Description: security support coverage checker
Sounds great. I was indeed unable to find anything that wouldn't be
too clunky
Do I understand that it does this by *containing lists* of packages
with such limits? Okay, so if LibreOffice (say) declares that the
version of their software in stable is now unsupported, how is that
information going to reach users who have debian-security-support
already installed (apart from via the security mailinglists they
should also be subscribed to, that is)? I would have expected this
package to have a cron-job downloading new lists and comparing them to
dpkg -l output, or maybe to receive package updates via the security
repository and automatically check for alerts via an apt hook. But
instead it seems to be essentially manual - is that correct?
If you don't want intemperate bug reports from people who guessed
wrong, you ought to answer this question in the package description.
I leave that to answer to the package maintainers..:-)
signature.asc
Description: Digital signature
Bug#747697: [RFR] templates://debian-security-support/{debian-security-support.templates}
Christian PERRIER wrote: I gather this template text is echoed by runtime messages from binaries in the package (since there's a messages.po with the same grammar problem). Should I give you a patch for that too? Would be a good idea, yes. Same for the manpage. I may be doing this wrong, but I attach a message-phrasing patch for the Bash script itself (on the assumption that the .po file just gets generated from it). And the check-support-status.txt file, which I gather is asciidoc source for the man page: CHECK-SUPPORT-STATUS(1) === NAME check-support-status - check installed packages for ended security support (Should that perhaps be reduced security support?) VERSION --- Version 2014.04.06 SYNOPSIS Search for packages with ended or limited support: check-supported-status XX No, that's not what it's called! Search for package with ended support from a manual list, report ^s (custom?) reporting each package only once: check-supported-status \ XX --type ended \ --semaphore /path/to/semaphore \ (Semaphore is a strange word to use for what appears to be a status database recording things that have already been reported, but I suspect it's already too late to change it.) --list /path/to/security-support-ended OPTIONS --- *--list* 'FILE':: Use the given file as database which packages are no longer ^the ^of supported or with limited support. The file format is plain text in have columns, separated by one or more characters. What kind of characters? Assuming it's not just spaces, I suspect: separated by one or more whitespace characters. + For `--type ended`: + -- * source package name * last version that package was supported I think this is trying to say: * last package version that is supported * the date supported was ended. XX X * the rest: An optional text or URL with further information. Is that some optional text, or a URL with further information, or is it optionally, (nothing, or) some text with further information, or a URL with further information? I'm guessing: * the rest: details, and/or a URL for further information. (I don't see any reason to forbid having both, if it'll fit.) -- + For `--type limited`: + -- * source package name * the rest: An optional text or URL with further information. Ditto. -- + If no --list is provided, the script is run for both ended and limited support, using the lists shipped in the package. *--dpkg* 'COMMAND':: The command to execute instead of dpkg. Mostly for tests. + Note: This does not override the usage when called as dpkg --compare-versions. *--dpkg-query* 'COMAND':: COMMAND The command to execute instead of dpkg-query. Mostly for tests. Wait... if this is a separate item, what non-querying, non-comparing dpkg calls was it talking about in the previous section? (Goes and looks) Apparently, only the call to dpkg --version. That seems a bit futile. Wouldn't it be simpler to have a --dpkg-version option? *--no-heading*:: Skips printing a headline. *--semaphore* 'FILE':: Use the given file to record alerts so each affected package is reported only once. + Default: No records, any affected package will be reported every time. *--type* 'TYPE':: One of the following: * ended: Alert for packages where security support has ended. * limited: Alert for packages where security support is limited. *--version, --Version, -V*:: Show the version number and exit. BUGS (More of a wontfix LIMITATIONS, really) Using mixed distribution like half-stable, half-testing is not supported. Mixed distributions (or perhaps a mixed distribution). [...] -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package --- debian-security-support-2014.05.16.pristine/check-support-status 2014-04-28 19:50:42.0 +0100 +++ debian-security-support-2014.05.16/check-support-status 2014-05-17 17:12:11.753387884 +0100 @@ -202,21 +202,22 @@ case $TYPE in ended) gettext \ -Security support has ended for one or more packages +Ended security support for one or more packages -Unfortunately, security support for some packages needed to be stopped -before the end of the regular security maintenance life cycle. +Unfortunately, it has been necessary to end security support for some +packages before the end of the regular security maintenance life cycle. -The following packages found on your system are affected by this: +The following packages found on this system are affected by this: echo ;; limited) gettext \
Bug#747697: [RFR] templates://debian-security-support/{debian-security-support.templates}
Justin B Rye wrote: *--dpkg-query* 'COMAND':: COMMAND Sorry, missing from the patch - revised version attached. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package --- debian-security-support-2014.05.16.pristine/check-support-status.txt 2014-04-28 19:50:42.0 +0100 +++ debian-security-support-2014.05.16/check-support-status.txt 2014-05-17 18:34:09.077718763 +0100 @@ -15,14 +15,14 @@ Search for packages with ended or limited support: -check-supported-status +check-support-status -Search for package with ended support from a manual list, report +Search for packages with ended support from a manual list, reporting each package only once: -check-supported-status \ +check-support-status \ --type ended \ --semaphore /path/to/semaphore \ --list /path/to/security-support-ended @@ -32,24 +32,24 @@ --- *--list* 'FILE':: -Use the given file as database which packages are no longer -supported or with limited support. The file format is plain text in -columns, separated by one or more characters. +Use the given file as the database of which packages are no longer +supported or have limited support. The file format is plain text in +columns, separated by one or more whitespace characters. + For `--type ended`: + -- * source package name -* last version that package was supported -* the date supported was ended. -* the rest: An optional text or URL with further information. +* last package version that is supported +* the date support was ended +* the rest: details, and/or a URL for further information. -- + For `--type limited`: + -- * source package name -* the rest: An optional text or URL with further information. +* the rest: details, and/or a URL for further information. -- + If no --list is provided, the script is run for both ended and @@ -62,7 +62,7 @@ Note: This does not override the usage when called as dpkg --compare-versions. -*--dpkg-query* 'COMAND':: +*--dpkg-query* 'COMMAND':: The command to execute instead of dpkg-query. Mostly for tests. @@ -90,7 +90,7 @@ BUGS -Using mixed distribution like half-stable, half-testing is not +Using mixed distributions like half-stable, half-testing is not supported. AUTHOR
