Christoph Brinkhaus:
Package: debhelper
Version: 13.20
Severity: minor

Dear Niels,

while updating the strings in the debhelper documentation the l10
documentation team noticed a few issues in the text which I report
in the attached text file.

Just for reference: The update of the german translation has been
reported in a separate report as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1083169.
The remarks listed below appear in the po template as FIXME, too.
The first two strings seem to be contradictionary to be.
The other ones are just typos or about formatting, nothing serious.

In case the documentation is updated I will be happy to update the
translation accordingly.

Thank you very much for maintaining this huge project,
Christoph Brinkhaus

Hi Christoph

Thanks for the feedback.

No. 1
# FIXME In #: debhelper-compat-upgrade-checklist.pod:276
#       it triggers a warning to use... Is just the context different?
#       Please clarify.
#. type: textblock
#: debhelper-compat-upgrade-checklist.pod:59
msgid ""
"It is now an error to use a packaging file without the package prefix for "
"B<--name> even if the source package only produces one binary package. As "
"example, if you had a F<debian/bar.service> with the following snippet in "
"F<debian/rules>:"

No. 2
# FIXME It is now triggers a warning → Now it triggers a warning
# FIXME In #: debhelper-compat-upgrade-checklist.pod:59
#       it is an error to use... Is just the context different?
#       Please clarify.
#. type: textblock
#: debhelper-compat-upgrade-checklist.pod:276
msgid ""
"It is now triggers a warning to use a packaging file without the package "
"prefix for B<--name> even if the source package only produces one binary "
"package. As example, if you had a F<debian/bar.service> with the following "
"snippet in F<debian/rules>:"


I am not sure I understand the contradiction here. The message is for two different compat levels (14 vs. 15). In compat 14 (no. 2) the behavior triggers a warning. In compat 15 (no. 1), the warning is replaced with an error which breaks the build.

The full description for compat 14 is:

"""
It now triggers a warning to use a packaging file without the package prefix for B<--name> even if the source package only produces one binary package. As example, if you had a F<debian/bar.service> with the following snippet in F<debian/rules>:

 override_dh_installsystemd:
    dh_installsystemd -p foo --name bar

Then you need to rename F<debian/bar.service> to
F<debian/foo.bar.service>.

In compat 15 (or later), this is changed to an error.
"""

The last line that makes the forward reference to compat 15. It is probably not that easy to see in the POT/PO files. I think the texts are split by paragraph in the POT/PO files and the last remark ends up being in its own "unrelated" paragraph. Alternatively, if you know the magic rune for getting a translator comment from POD (via po4a) into the POT/PO files, I can also add one of those.

Alternative wording proposals are welcome.

Also, fixed the "It is now triggers a warning" typo, thanks.


No. 3
# FIXME does "resultig deb" mean "resulting deb file"?
#. type: textblock
#: debhelper-compat-upgrade-checklist.pod:108
msgid ""
"Additionally, B<dh_strip_nondeterminism> and B<dh_compress> plus any "
"commands added by third-party add-ons using these as anchors will no longer "
"be able to rely on the mode/ownership normalization by B<dh_fixperms>, which "
"may expose bugs in the form of incorrect mode or ownership in the resulting "
"deb."


Yes. Replaced it with "resulting binary package". The problem can also affect udebs in theory, so "deb" was also not great for other reasons.

No. 4 (from here downwards just typos/formatting...)
# FIXME now assumes → now assume
[...]

No. 5
#FIXME --remove → B<--remove>
#FIXME --purge → B<--purge>
[...]


No. 7
# FIXME B<XDG_*> variable → B<XDG_*> variables
[...]

No. 8
# FIXME that relies → that rely
#. type: textblock
[...]

Thanks, fixed these.

> No. 6
> # FIXME B<lintian> → B<lintian>(1)
> [...]

Thanks, also fixed this one in 2 more places.

Best regards,
Niels


Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to