Bug#923916: O: utfcheck -- check validity of UTF-8 in text files
Package: wnpp
Bug#923915: O: utf8gen -- generate well-formed UTF-8 characters
Package: wnpp
Bug#923913: O: unibetacode -- convert polytonic Greek and Coptic between Beta Code and Unicode
Package: wnpp
Bug#923914: O: unifont -- pan-Unicode font and utilities
Package: wnpp
Bug#700576: cowsay: Please add a kangaroo cow
Control: tags -1 + patch This patch changes the version of the kangaroo cow salsa merge from an NMU, "-5.1", to a QA upload, "-6" (because the package is orphaned) and makes the kangaroo cow license "GPL-2+". Thanks, Paul Hardy diff -u -r -N nmu-kangaroo/debian/changelog qa-kangaroo/debian/changelog --- nmu-kangaroo/debian/changelog 2018-11-10 06:02:59.0 -0800 +++ qa-kangaroo/debian/changelog 2019-02-03 09:39:39.272895685 -0800 @@ -1,9 +1,9 @@ -cowsay (3.03+dfsg2-5.1) unstable; urgency=medium +cowsay (3.03+dfsg2-6) unstable; urgency=medium - * Non-maintainer upload. - * Add kangaroo cow. + * QA upload. + * Add kangaroo cow (closes: #700576). - -- Paul Hardy Sat, 10 Nov 2018 05:40:41 -0800 + -- Paul Hardy Sun, 03 Feb 2019 09:39:28 -0800 cowsay (3.03+dfsg2-5) unstable; urgency=medium diff -u -r -N nmu-kangaroo/debian/copyright qa-kangaroo/debian/copyright --- nmu-kangaroo/debian/copyright 2018-11-10 06:20:40.0 -0800 +++ qa-kangaroo/debian/copyright 2019-02-03 09:35:54.219604693 -0800 @@ -46,7 +46,7 @@ Files: cows/kangaroo.cow Comment: Adapted from http://sumaleth.com/files/row_ascii_collection_1.2.html. Copyright: Copyright (C) 1994 Rowan Crawford. -License: GPL2+ +License: GPL-2+ This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or nmu2qa-kangaroo.patch.sig Description: PGP signature
Bug#910548: base-files - please consider adding /usr/share/common-licenses/Unicode-Data
Unicode's new version for 2019 is attached, with data files in http://www.unicode.org/ivd/data/ explicitly mentioned as covered under the license. The source text is at http://www.unicode.org/copyright.html. Thanks, Paul Hardy Unicode-Data Description: Binary data Unicode-Data.sig Description: Binary data
Bug#919545: ITP: c-graph -- interactive visualization tool for the convolution theorem
Package: wnpp Owner: Paul Hardy Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Package name: c-graph Version: 2.0.1 Upstream Author: Adrienne Gaye Thompson URL: https://www.gnu.org/software/c-graph/ License: GPL-3+, GFDL-1.3+ Programming Language: Fortran 95 Description: interactive visualization tool for the convolution theorem GNU C-Graph is a novel tool for visualizing the mathematical operation of convolution. "C-Graph" is an abbreviation for "Convolution Graph". A game changer, C-Graph -- the de facto tool for visualizing the convolution theorem in universities worldwide -- is invaluable for lecture demonstrations and lab work in the teaching of signals and systems, as well as other courses featuring convolution. GNU C-Graph is widely used across industries that utilize signal processing techniques for design, test, and development: telecommunications, instrumentation and control, manufacturing, automotive, aviation and aerospace, medical devices, and others. This nifty package seamlessly generates publication quality graphics for papers, lecture demonstrations, and other professional presentations. . GNU C-Graph is interactive, prompting the user to enter character or numerical values from the keyboard - dispensing with the learning curve for writing code. A Texinfo manual provides sample sessions and an overview of the convolution theorem. C-Graph computes the linear convolution of two signals in the time domain then compares their circular convolution by demonstrating the convolution theorem. Each signal is modeled by a register of discrete values simulating samples of a signal, and the discrete Fourier transform (DFT) computed by means of the fast Fourier transform (FFT). . Select, Transform, Visualize : GNU C-Graph makes visualizing convolution easy Uploading this package will close the associated RFP bug #694088 filed in 2012. -- Paul Hardy
Bug#918384: [PATCH 5/6] documentation style: Do not put "" around C<..>
On Fri, Jan 11, 2019 at 2:02 PM Ian Jackson wrote: > > In the default text manpage rendering, C produces a pair of quotes and > the result is "".."" which is not desirable. On the other 5 patches: ack. On this patch: interesting. What I actually proofread was the PDF output of pod2man --> groff -man --> ps2pdf because a Roman font is easier to read than a monospace font. groff did not add the double quotes. But man output is what 99% of everybody will read, so that's what matters (which is why I backed out of my attempts at a grave accent for "a la" when "\`" and "\(ga" didn't render properly in man). > > Signed-off-by: Ian Jackson > --- > git-debrebase.1.pod | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/git-debrebase.1.pod b/git-debrebase.1.pod > index e5b84a0b..aa7f459b 100644 > --- a/git-debrebase.1.pod > +++ b/git-debrebase.1.pod > @@ -420,7 +420,7 @@ failure to find an appropriate upstream. > Directory to look in for orig tarballs. > The default is the git config option > dgit.default.build-products-dir > -or failing that, "C<..>". > +or failing that, C<..>. > Passed on to dgit, if git-debrebase invokes dgit. > > =item --[no-]origs > -- > 2.11.0 > Thanks again, Paul Hardy
Bug#918384: dgit: typo suggestions in man pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Ian, The patches I submitted for Debian bug #918384 were created entirely by me, except for those changes Sean suggested that I incorporated in the second patch set. Attached is a signed Developer's Certificate of Origin for your records. Thank you, Paul Hardy unifoun...@unifoundry.com -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEldLpq4dA2ARjh/0VGgkiex9DWjMFAlw5WKYACgkQGgkiex9D WjPiMRAAn+kaAjVNryGhc2C5B2LqiYq9RYAdvLzc34tgfit9zWm+qJ4WZwLG3L38 XEltBBYwDb4vV29ObdgLsxw/SI6gFK9FuqY0l94ZMcRoA/M7I2h2aOTrPIyhQRlN 0nEb7e1ceh0aaUHMQKRueXCJ28bP38DdFOe+sjZ3aeJL1A4HbhMQfVU5ou8HGti+ DB4oos2I9KSKOjV481TmMKcf9/EfmN1brKEVS13xdKbY+LBx7BfNHP0VQjli62yI a7XVhuntMEekPg8i0MqvBRIPNjpLv9zCNU76FBjJpOkJg1Bv8e7Ae6GRiFuxyBA3 5Hfa6OoBqLvKqDi9kftyD8pwB1+UKjqC/RJIxlFUuQNtwU/LB2Pu+NjpNM1aXIgw OspOh95KwfyjNkl83P/vHjnO5q7ioIYp2Gex3tQjqNjoKPj5YqGnUvbXyIiquL7D Gfjk+geclBvfzB7Z+iMeQcQhcAScoGx7i8tOu9rljdmHIlnLV8vyYwqsc+PrRc3x p/NmzkrwD8kz0FumhIhOlkBk4QlxjSm8vXSu5GvovjdoqUQVJX48lnHeuP2BAhk1 oHmTm4vd8yca8HKxZxjmT8HvQKuG6uudalDPRw9JASzdVf7oS/GgT0AsmJU+V3+x Vl6M63qxt3N+FCelj/4Cxuo3uxZf8ezbdKqn0yIMAUbJ/GZ1Mtk= =NmjB -END PGP SIGNATURE- -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Developer Certificate of Origin Version 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129 Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. Signed-off-by: Paul Hardy -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEldLpq4dA2ARjh/0VGgkiex9DWjMFAlw5WGgACgkQGgkiex9D WjNp+xAArO0H3RdWhxylAlR594/JYikvKEe8NiBY3HEwOxEgwUeqLKDEZrGqCVvs ZYzrZ1psNABdxDXCzlT2jq8glrOz+mq+CNLhryuYwDR0T9IBXziW1NVDXaq15M5y sdgvncefUwcXm433ALsNl0Yth4Y+6ptcxLKARZ+BRZUTRyOv9EszqkryPpo3epk9 8RTEVmtNfJZqkDGrfrWOPTxS5B6nN/wliZb7zhxY0dozl4ex58UVJAHhRYER5et6 Im6dpaD2sPS+dE/z5gD40eIclPY473sTmiET99kgbSO7kcoBcCA2RUUR+rjpHLel syle0fxgbMv/MtA+/UgWuuVX/kNqXJBFcu/aITrBj7V8mLBsWGM/oR4LOrlJRVSK PBD+TyvL50k5rNO9CVsuNBHZkeSFFDHFWM7EuZzJpOv1l92USaSluVGUE57LR1cf nlpaXh7tqjGGQRnEJs+05Aw71PkmKfJz6VkEFtbkh9wwwqXJf60kT5QSo50mt489 HWbJkixlzOjTU5OrG8Hy5mmPOYo3hRrAx3mPCMh+sAR5bgIZSJ5bAtTcLHnb3CkC fnuXuSQuan0BzfoRw0kwPpQxOatRXDy3U3WWUsC1AB0BIaCmILYylGv4U/dU+2nT GVnB8CFNPl68bDzPJGYqIUsb8RdLinq5tQBh44eCnRw0o+cmz64= =f//v -END PGP SIGNATURE-
Bug#918384: dgit: typo suggestions in man pages
Ian and Sean, Thank you for such a quick review. Here is another git format-patch submission that incorporates the feedback from you both, for dgit version 8.3 this time. I saw no new typos in version 8.3 document changes. I left "a la" as is given that Debian's man command doesn't properly position the grave accent. On Sat, Jan 5, 2019 at 12:18 PM Sean Whitton wrote: > > On Sat 05 Jan 2019 at 09:19am -0800, Paul Hardy wrote: > > > -You should also write appropriate dput configuration, > > +You should also write an appropriate dput configuration, > > Either "appropriate dput configuration" or "an appropriate dgit > configuration file", but not "an appropriate dput configuration", I > think. I used your second choice this time: "an appropriate dgit configuration file". > > @@ -355,7 +355,7 @@ in .git/info/attributes, > > but it is insufficient, > > because it was made by an earlier version of dgit > > and git has since introduced new transforming attributes, > > -modifies the macro to disable the newer transformations. > > +this modifies the macro to disable the newer transformations. > > I think the comma just before your change now needs to be a semicolon. Added a semicolon this time. > > .BR dgit-distro. \fIdistro\fR .clean-mode-newer > > Like .clean-mode, > > -but ignored if the value does not make sense to this version of dgit. > > +but ignored if the value does not make sense for this version of dgit. > > I think this is wrong. Perhaps s/does not make sense to/is unknown to/. Changed to "is unknown to" per your feedback. I thought perhaps the original sounded anthropomorphic but made it only as a suggestion. > > -It should only be used with a care and > > +It should only be used with care and > > "It should be used only with care"* I used your suggestion of "It should be used only with care". All the best, Paul Hardy 0001-typo-suggestions-from-Paul-Hardy.patch.sig Description: PGP signature From a933237851ea55b23df87f869dd96b731a553d3c Mon Sep 17 00:00:00 2001 From: Paul Hardy Date: Wed, 9 Jan 2019 22:35:39 -0800 Subject: [PATCH] typo suggestions from Paul Hardy --- dgit-downstream-dsc.7.pod | 10 +- dgit-maint-debrebase.7.pod | 6 +++--- dgit-maint-native.7.pod| 2 +- dgit-sponsorship.7.pod | 2 +- dgit-user.7.pod| 2 +- dgit.1 | 25 + dgit.7 | 4 ++-- git-debrebase.1.pod| 14 +++--- git-debrebase.5.pod| 22 +++--- 9 files changed, 44 insertions(+), 43 deletions(-) diff --git a/dgit-downstream-dsc.7.pod b/dgit-downstream-dsc.7.pod index fcbce05..ace4fbf 100644 --- a/dgit-downstream-dsc.7.pod +++ b/dgit-downstream-dsc.7.pod @@ -121,8 +121,8 @@ but in most installations this is not needed. If there is no or little distinction between (i) developers who are entitled to upload (push) and (ii) repository administrators, -then a it is sufficient to provide a -git server with a unix account for each user who will pushing, +then it is sufficient to provide a +git server with a unix account for each user who will be pushing, perhaps using ssh restricted commands. =item Debian-format archive (repository) @@ -140,7 +140,7 @@ In this document we will assume you are using B. Setting up reprepro is not covered in this tutorial. Instead, we assume you already have reprepro working. -You should also write appropriate dput configuration, +You should also write an appropriate dput configuration file, since dgit uses dput to upload packages to the archive. This will involve choosing a dput host name. That's probably your distro name, I. @@ -216,7 +216,7 @@ yet a git repository for a particular package. If you always have a git repository for every package in your archive, perhaps because you never use dput/dupload, and always dgit push, -Set C to B. +set C to B. Otherwise, set C to a url prefix - ideally, https. dgit clone will try to fetch @@ -312,7 +312,7 @@ Either don't do that, or set up B. When a user who can push runs dgit, dgit uses ssh to access the git server. -To make ssh restricted command easier, +To make the ssh restricted command easier, and for the benefit of dgit-repos-server, dgit's ssh commands each start with a parseable commentish rune. diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod index 4996e6a..b91ed16 100644 --- a/dgit-maint-debrebase.7.pod +++ b/dgit-maint-debrebase.7.pod @@ -376,7 +376,7 @@ release: =back Pass I<--stat> just to see the list of changed files, which is useful -to determine whether there are any new or deleted files to may need +to determine whether there are any new or deleted files that may need accounting for in your copyright file. If you
Bug#918384: dgit: typo suggestions in man pages
On Mon, Jan 7, 2019 at 2:44 AM Ian Jackson wrote: > .. > You are using git for this, right ? Yes. That is how I generated the git format-patch file. If you can give me a couple of days I will look over the 8.3 man page changes as well. Thanks, Paul Hardy
Bug#918384: dgit: typo suggestions in man pages
Ian, On Sun, Jan 6, 2019 at 11:39 AM Ian Jackson wrote: > ... > As for the rest, I agree with Sean's comments. Paul, would you care > to respin the patch ? I'm planning an upload soon today but I can > wait a few hours if that would get thwse changes included. I trust that after you sent this you saw an email I sent beforehand mentioning that I would be unavailable today. I hope you did not delay your dgit upload on my account. I was not aware of the poor timing. Did any of the man pages change in your version 8.3 upload from version 8.1? If not, that will simplify my creating the modified patch. All the best, Paul Hardy
Bug#918384: dgit: typo suggestions in man pages
Sean,
On Sat, Jan 5, 2019 at 12:18 PM Sean Whitton wrote:
>
> [Please use X-debbugs-cc: rather than Cc: when you want a new bug to be
> copied to someone else. I had to look up the bug number in order to be
> able to reply.]
Sorry, wasn't thinking. I added your name at the last moment.
> Hello Paul,
>
> Thank you for your interest. Here is a review of the patch.
>
> On Sat 05 Jan 2019 at 09:19am -0800, Paul Hardy wrote:
>
> > dgit clone needs to be told the source package name
> > -(which might be different to the binary package name,
> > +(which might be different from the binary package name,
>
> Aren't either acceptable in contemporary English? ('to' is what I would
> expect myself to write)
I'm accustomed to "different from", but I am not a grammarian. :-)
Whichever you prefer.
> > @@ -355,7 +355,7 @@ in .git/info/attributes,
> > but it is insufficient,
> > because it was made by an earlier version of dgit
> > and git has since introduced new transforming attributes,
> > -modifies the macro to disable the newer transformations.
> > +this modifies the macro to disable the newer transformations.
>
> I think the comma just before your change now needs to be a semicolon.
Yes, it does. I missed that.
> > -the latter unless the former exists on PATH.)
> > +the latter unless the former exists in PATH.)
>
> This is wrong. "in PATH" suggests actually present in the string PATH;
> "on PATH" means in one of the directories specified by PATH, AFAIK.
Okay.
> > -Whether to setup a merge driver which uses dpkg-mergechangelogs for
> > +Whether to set up a merge driver which uses dpkg-mergechangelogs for
>
> I think this is wrong. AIUI, 'setup' is a noun and 'set up' is a verb.
Right, so it seemed it was being used as a verb; hence "set up". One
way or another, everybody will know what is meant of course.
All the best,
Paul Hardy
Bug#918384: dgit: typo suggestions in man pages
Package: dgit
Version: 8.1
Severity: wishlist
Tags: patch
Hello,
Attached are some typo suggestions as a git format-patch file.
One suggestion you may want to decline, in dgit.7: "\`a la" instead of
"a la"; nroff/man on Debian does not form the grave accent correctly;
not sure why.
I did not add periods to any Latin abbreviations ("eg" != "e.g.", "et
al" != "et al.", and so on).
I think I only made one other typographical change, in
git-debrebase.1.pod: C<..>. ==> "C<..>". so the ".." would stand out
better.
In git-debrebase.5.pod, after "reified" I added " [re-quiltified?]" as
a guess of what you meant. You'll want to change that accordingly.
Thanks,
Paul Hardy
0001-typo-suggestions-from-Paul-Hardy.patch.sig
Description: PGP signature
From a90cee7d6b2a89ced11baf0755299cb8b27108cc Mon Sep 17 00:00:00 2001
From: Paul Hardy
Date: Sat, 5 Jan 2019 08:42:10 -0800
Subject: [PATCH] typo suggestions from Paul Hardy
---
dgit-downstream-dsc.7.pod | 10 +-
dgit-maint-debrebase.7.pod | 6 +++---
dgit-maint-native.7.pod| 2 +-
dgit-sponsorship.7.pod | 2 +-
dgit-user.7.pod| 4 ++--
dgit.1 | 25 +
dgit.7 | 6 +++---
git-debrebase.1.pod| 14 +++---
git-debrebase.5.pod| 26 +-
9 files changed, 48 insertions(+), 47 deletions(-)
diff --git a/dgit-downstream-dsc.7.pod b/dgit-downstream-dsc.7.pod
index fcbce05..78c18f7 100644
--- a/dgit-downstream-dsc.7.pod
+++ b/dgit-downstream-dsc.7.pod
@@ -121,8 +121,8 @@ but in most installations this is not needed.
If there is no or little distinction between
(i) developers who are entitled to upload (push) and
(ii) repository administrators,
-then a it is sufficient to provide a
-git server with a unix account for each user who will pushing,
+then it is sufficient to provide a
+git server with a unix account for each user who will be pushing,
perhaps using ssh restricted commands.
=item Debian-format archive (repository)
@@ -140,7 +140,7 @@ In this document we will assume you are using B.
Setting up reprepro is not covered in this tutorial.
Instead, we assume you already have reprepro working.
-You should also write appropriate dput configuration,
+You should also write an appropriate dput configuration,
since dgit uses dput to upload packages to the archive.
This will involve choosing a dput host name.
That's probably your distro name, I.
@@ -216,7 +216,7 @@ yet a git repository for a particular package.
If you always have a git repository for every package in your archive,
perhaps because you never use dput/dupload, and always dgit push,
-Set C to B.
+set C to B.
Otherwise, set C to a url prefix - ideally, https.
dgit clone will try to fetch
@@ -312,7 +312,7 @@ Either don't do that, or set up B.
When a user who can push runs dgit,
dgit uses ssh to access the git server.
-To make ssh restricted command easier,
+To make the ssh restricted command easier,
and for the benefit of dgit-repos-server,
dgit's ssh commands
each start with a parseable commentish rune.
diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index f167928..8a182dd 100644
--- a/dgit-maint-debrebase.7.pod
+++ b/dgit-maint-debrebase.7.pod
@@ -376,7 +376,7 @@ release:
=back
Pass I<--stat> just to see the list of changed files, which is useful
-to determine whether there are any new or deleted files to may need
+to determine whether there are any new or deleted files that may need
accounting for in your copyright file.
If you obtained a tarball from upstream, you are ready to try a build.
@@ -451,7 +451,7 @@ In some cases where you used B since
the last upload, it is not possible for dgit to make your history
fast-forwarding from the history on B. In such cases you
will have to pass I<--overwrite> to dgit. git-debrebase will normally
-tell you if this is will be needed.
+tell you if this will be needed.
Right before uploading, if you did not just already do so, you might
want to have git-debrebase(1) shuffle your branch such that the Debian
@@ -545,7 +545,7 @@ In the simplest case,
=back
-If that fails, because your branch and the NMUers work represent
+If that fails, because your branch and the NMUers' work represent
divergent branches of development, you have a number of options. Here
we describe the two simplest.
diff --git a/dgit-maint-native.7.pod b/dgit-maint-native.7.pod
index ac57728..792be10 100644
--- a/dgit-maint-native.7.pod
+++ b/dgit-maint-native.7.pod
@@ -85,7 +85,7 @@ is fast forward from the dgit archive view.
Alternatively,
if this was the first ever dgit push of the package,
you can avoid this merge commit by
-passing C<--deliberately-not-fast-forward>.
+passing C<--deliberately-not-fast-forward>
instead of C<--overwrite>
Bug#700576: cowsay: Please add a kangaroo cow
I have submitted a merge request for this on salsa.debian.org. Thanks, Paul Hardy
Bug#700576: cowsay: Please add a kangaroo cow
Here is a kangaroo cow NMU patch created with "diff -r -N -u". The directories are "cowsay-3.03+dfsg2-5" (current Debian unstable version) and "cowsay-3.03+dfsg2-5.1" (kangaroo cow NMU version). Thanks, Paul Hardy cowsay-kangaroo-patch.txt.gz.sig Description: PGP signature cowsay-kangaroo-patch.txt.gz Description: application/gzip
Bug#700576: cowsay: Please add a kangaroo cow
Control: tags -1 + pending - help I am going to prepare an NMU to fix this bug using the patch that I submitted previously. Thanks, Paul Hardy
Bug#910548: base-files - please consider adding /usr/share/common-licenses/Unicode-Data
On Thu, Oct 18, 2018 at 11:22 PM Russ Allbery wrote: > > ...It therefore probably isn't meaningfully under > any license, although including the Unicode Data License in the package > doesn't hurt. That was my thinking. Plus it would have been acutely embarrassing to run afoul of the Unicode Consortium's license terms, even if unintentional, after they so kindly gave me a lifetime membership gratis[1]. :-) > Disclaimer: I'm not a lawyer, let alone a copyright lawyer. Me neither, so I erred on the side of caution. Thanks, Paul Hardy [1] http://unicode.org/consortium/members.html
Bug#910548: base-files - please consider adding /usr/share/common-licenses/Unicode-Data
Josh, I understand your intention, but it's not that straightforward. The data that I saw in Debian packages I looked through used various pieces of property data from various files from the Unicode Consortium within pre-built arrays also containing other data, though I didn't look through all packages that used Unicode data by any means. In my case, I used Unicode code point descriptions in the comment fields of lex patterns (flex on Debian) in my beta2uni program (part of my unibetacode package), which converts Beta Code to Unicode. Here are a few such lines of code: \*\/[Aa] print_pattern (yytext, 0x0386); /* GREEK CAPITAL LETTER ALPHA WITH TONOS*/ \*\/[Ee] print_pattern (yytext, 0x0388); /* GREEK CAPITAL LETTER EPSILON WITH TONOS */ \*\/[Hh] print_pattern (yytext, 0x0389); /* GREEK CAPITAL LETTER ETA WITH TONOS */ \*\/[Ii] print_pattern (yytext, 0x038A); /* GREEK CAPITAL LETTER IOTA WITH TONOS */ \*\/[Oo] print_pattern (yytext, 0x038C); /* GREEK CAPITAL LETTER OMICRON WITH TONOS */ \*\/[Uu] print_pattern (yytext, 0x038E); /* GREEK CAPITAL LETTER UPSILON WITH TONOS */ \*\/[Ww] print_pattern (yytext, 0x038F); /* GREEK CAPITAL LETTER OMEGA WITH TONOS*/ etc. I used the utf8gen program (another package that I wrote and then debianized) to create those lines of code, typing in the regular expressions myself by hand after utf8gen did the monotonous work of printing everything to the right of those patterns on each line for me from data that I had pre-extracted from a Unicode data file. I had to have the Unicode names in front of me to type the correct regular expression for each code point. The way I did that also will help me or anyone else debug the program in the future. Were I to attempt to pull such comment strings from another package on the fly, I would have to write a program that knew which lines in my source code needed those comment strings, fetch them from said external package, and create a new source code file for lex/flex before building the final program. Apart from the most obvious immediate inconveniences of doing that, two others come to mind: 1) I could not then produce the source file in final form without running on a distro such as Debian that implemented a packaging scheme, or providing complicated build instructions for an end user (most likely a student of ancient Greek who would not have deep knowledge of building software packages). As implemented, my unibetacode package builds and installs on many distros just the way it is, including on non-GNU/Linux systems thanks to the modern miracle of GNU Autotools. 2) I would have to perform such a partial build just to read the comments that I intended for debugging (and I would have had to resort to an external table while typing in the generating regular expressions rather than having them conveniently on the same line of code). There would also be the impracticality of telling such groups as the Linux kernel developers and other upstream teams that they must switch to using the Unicode package that Debian provides for their future builds. OTOH, packaging the Unicode data files could be useful for other, unrelated purposes. Of course, such a package would be one more instance of the need for the Unicode Consortium's license and (lengthy) copyright information in yet one more package's debian/copyright file. :-) Yet that still doesn't answer the question of whether or not Debian would find such a common file of Unicode license & copyright terms useful...but the text is there if Debian makes that decision. If not, at least I took the time to make it available. Thanks, Paul Hardy
Bug#885698: Update and document criteria for inclusion in /usr/share/common-licenses
Control: block 910548 by -1 Blocking my own bug report with this one, which I just noticed. I submitted bug #910548 previously against the base-files package: "base-files - please consider adding /usr/share/common-licenses/Unicode-Data". I had formatted the copyright and license information for Unicode data files from the http://unicode.org website to put in the debian/copyright file in a package that I created this summer. The copyright information is more involved than most copyright statements, so I kept it in what I submitted with the bug report. I thought if that license was something Debian found useful, there would be no need for anyone else to duplicate the effort of formatting that I had gone through once, and so I offered it. Just the license in isolation could be formatted like other licenses fairly quickly if the copyright section is not wanted. Or the whole thing can be left out and that bug closed, as you wish. Thanks, Paul Hardy
Bug#700576: cowsay: Pleasy add kangaroo cow :)
tags -1 patch Attached is a kangaroo cow, all ready to be copied to the cows directory. The file author, copyright, and license are given in comments in the header. I am also attaching the email exchange where the creator of the kangaroo gave permission to use that kangaroo (after I flipped it horizontally) with the stated copyright and license terms. Francois, this package has no maintainer right now so if you want to upload this patch please do. The header information in kangaroo.cow could be copied into debian/copyright as well. Have fun! Thanks, Paul Hardy kangaroo.cow Description: Binary data permission.txt.gz.sig Description: PGP signature permission.txt.gz Description: application/gzip kangaroo.cow.sig Description: PGP signature
Bug#776413: Policy violation: ed priority "optional", should be "important"
I considered using "ed" in a script to massage an upstream package into shape during installation this past week, but decided not to because ed is not part of the default Debian installation. I think it is worth considering why ed is part of the POSIX standard to this day in determining whether or not it should have priority "important" and be included in the base installation. The very first sentence of the "DESCRIPTION" portion of the BSD 4.2 man page (1980s vintage) for ed says: "_Ed_ is the standard text editor." Historically, ed was the only text editor available on a bare-bones Unix system booting from a minimal kernel before a customized kernel had been configured and built, with video drivers, etc., to support video monitors. Most processors today are not connected to video monitors; most processors are part of embedded systems. When bringing up such a system initially, you typically just have a power supply, the processor chip, some flash memory that contains a minimal bootloader, a serial console port on the processor's UART pins, and maybe a JTAG port. This bug report has mentioned vi(m) and sed as possible replacements. Neither are proper interactive single-line editors designed to work over a serial line, and GNU sed is more powerful than other sed implementations, and vi(m) is not suitable for operation within a shell script. Embedded systems are not going to be reporting their usage for popcon statistics either, so a poor popcon showing can be misleading. The Debian source package is about 1 Mbyte, almost half of which is testsuite data, but the upstream tarball is less than 70 kilobytes. Is Debian so constrained for space on its ISO images that it is not possible to shoehorn in a copy of ed in the base installation? I know that the package priority is up to the FTP Masters and not up to any of us. I just mention the above as input for the ed maintainer to discuss with the FTP Masters if so desired. Thank you, Paul Hardy
Bug#907725: Fwd: Appropriate Section for PCF Fonts
Chris, On Mon, Oct 8, 2018 at 9:41 AM Chris Lamb wrote: > > Paul, > > > [..] > > Unfortunately I have very little insight or input to share on fonts or > sections more generally in Debian so I will just have to leave this up > to someone else. Apologies that I could not make progress here. All's well that ends well. I know now that the status quo is just fine with my package. > (I do somehow doubt a mass bug filing would be really appropriate or > welcome, mind you. I'm sure many facing the business end of a mass bug filing would find displeasure with it. :-) I expected that would be the least popular option. But IMHO I felt that if it was a bug, there should be a bug filing against my package, and if it was not a bug, then the lintian message should probably be removed. > Did you consider "fixing" Lintian instead?) Indeed I did, but I was not sure how to approach the issue properly, so I posed the question on debian-policy thinking that might be the best place to start[1]. I only received one response, which indicated that section assignment was within the purview of the FTP Masters[2], so then I followed up with an email to them. In retrospect, I have learned by seeing how Russ phrased this bug report. Chalk one more up for experience... > Again, sorry I can't be of more help. Actually, this bug that Russ filed is being resolved by taking two of the actions that I asked about in the debian-policy mailing: the lintian message will be removed, and "fonts" will be removed from the web page description of the "x11" section, so that certainly helps. Note, however, that there _are_ a few "xfonts-*" fonts in the "x11" section. If you and the rest of the FTP Team agrees, I suppose you could change the lintian message to encourage those packages to set their d/control section to "fonts". Sorry I did not notice this bug until just before it was to be archived. I only saw it while searching to see if another bug had been filed about something else in lintian (concerning "wrong-path-for-interpreter" with the relaxed 4.2.1 policy), and in fact that bug was already filed by someone else and already closed (#908350). Thank you for your detailed responses, Paul Hardy [1] https://lists.debian.org/debian-policy/2018/06/msg00098.html [2] https://lists.debian.org/debian-policy/2018/06/msg00099.html
Bug#907725: Fwd: Appropriate Section for PCF Fonts
Russ,
On Sun, Oct 7, 2018 at 3:59 PM Russ Allbery wrote:
>
> Paul Hardy writes:
>
> > Thank you for dealing with bug #907725 ("xfonts packages are not using
> > the x11 section in practice"). I was told that it was up to the FTP
> > Masters, so I wrote the below email to them in July. I have not yet
> > received a response, but looking at the NEW queue it is obvious how
> > swamped they are so I wasn't expecting a rapid response.
>
> Just in case you weren't already aware of this little-known corner of how
> the Debian archive works: the section of every package currently in the
> archive is set via the overrides maintained by ftp-master, not by the
> section specified in the packaging files. This is for somewhat esoteric
> and historical reasons, but the package metadata is basically just a hint.
>
> Therefore, even though you didn't get a reply, ftp-master has in a sense
> already made their decision clear: the fonts currently in the archive are
> in the fonts section. If ftp-master had wanted them in a different
> section, that's entirely under their control, and they could have just
> made that change.
Thanks for taking the time to explain this. I was aware of the FTP
package mapping in principle, but do not know the actual mechanics of
it. The lintian message seemed like it might signal some upcoming
change in placing those files, and I wanted to do the right thing
before the freeze.
Take care,
Paul Hardy
Bug#910548: base-files - please consider adding /usr/share/common-licenses/Unicode-Data
Package: base-files Severity: wishlist Tags: patch Hello, I recently formatted the Unicode Data license for the d/copyright file of a Debian package that I created. I thought I would offer it to Debian if you are interested. You probably do not want the Copyright stanza, and you might not want the Comment stanza, but I erred on the side of too much rather than too little. Unicode data files are used in a number of free software packages, such as linux-libc-dev and the Linux kernel itself. Use of Unicode data in software is likely to continue growing over time. Thus you might find this useful. Thank you, Paul Hardy Unicode-Data.sig Description: PGP signature Unicode-Data Description: Binary data
Bug#907725: Fwd: Appropriate Section for PCF Fonts
Chris,
Thank you for dealing with bug #907725 ("xfonts packages are not using
the x11 section in practice"). I was told that it was up to the FTP
Masters, so I wrote the below email to them in July. I have not yet
received a response, but looking at the NEW queue it is obvious how
swamped they are so I wasn't expecting a rapid response.
Sincerely,
Paul Hardy
-- Forwarded message -----
From: Paul Hardy
Date: Mon, Jul 30, 2018 at 6:40 AM
Subject: Appropriate Section for PCF Fonts
To:
Dear FTP Masters,
I am preparing a new upload of my Unifont package, which includes a
PCF font. I get a lintian warning that the PCF font is not in the "X
Window System" section. The sid section page
(https://packages.debian.org/sid/) mentions fonts as one thing
appropriate for that section.
There is also a "fonts" section of course, and that is where all of
the Unifont fonts are now (and have been for over 10 years).
There are a lot of PCF fonts in the fonts section, and it looks like
almost none in the "X Window" section. Any font today can be used by
more than the X Window System, so my inclination is to keep PCF fonts
in the "fonts" section.
To clarify things with font maintainers, can you either have a mass
bug filing against all PCF fonts that are in the fonts section, or
remove "fonts" from the list of package types suitable for the "X
Window" section. And if you remove fonts from the "X Window" section
list, the current lintian warning (when a PCF font is in the "fonts"
section) should be removed.
If you want to file a mass bug report, this would probably be a good
time, as it would give font package maintainers time to upload new
versions before the buster freeze.
Thank you,
Paul Hardy
Bug#907915: developers-reference: language in manual
Control: tags -1 patch Is the attached patch acceptable? I verified that OUTOFSYNC_ARCHES is set to null in the latest britney2 source. Thanks, Paul Hardy changes.patches.gz.sig Description: PGP signature changes.patches.gz Description: application/gzip
Bug#907846: autopkgtest: Please consider additional section for tutorial web page
A general comment: although this TUTORIAL file originally was just meant to reflect one talk from 2015, I recommend letting it evolve to be _the_ tutorial for using autopkgtest in the Debian CI environment, because this is one link that search engines find when someone searches for "autopkgtest tutorial", and it has "tutorial" in its name. There are autopkgtest information files all over the place, and it isn't immediately clear which should be an "official" Debian reference tutorial. Ideally this TUTORIAL file could evolve into _the_ tutorial, rather than having someone go through every link they can find trying to piece things together (which is what I did). On Tue, Sep 4, 2018 at 11:59 AM Paul Gevers wrote: > ... > You're looking at this file: > https://salsa.debian.org/ci-team/debci/blob/master/docs/TUTORIAL.md > > It would be awesome if you could propose changes to that file instead of > the generated html file. However, I already have some comments. I did not know that the HTML document I changed had its origin in another format. I _could_ modify the md file, but I do not work in md usually and I would be taking a chance of something being lost in translation. If nobody who is familiar with the Debian md format has time I can do that, but then please compare any formatting with the HTML file that I submitted; I do know HTML well and what I did there is what I intended. HTML is my native language. :-) > > On 03-09-18 06:42, Paul Hardy wrote: > > Please consider adding "The test environment" section (or something > > like it) that I added to the autopkgtest tutorial page. It gives an > > introductory description of the general environment in which a CI test > > script runs in a way that I have not found elsewhere. > > Although I appreciate what you try to do here, it rather feels weird, as > you are just describing a very standard Debian setup. I really think > this is not the place to describe how Debian works and where packages > install their files. Policy already does that. So your first paragraph > could be "The test environment is a minimalistic standard Debian > installation." That is good, but I would still make it clear that the installation is not in some sub-tree (for example, /var/tmp/ci/sid/...). I would explicitly mention as an example that data files for "mypackage" are in "/usr/share/mypackage". That should get the point across. > > Your second sentence basically repeats stuff that is in the autopkgtest > spec. Maybe we should more clearly link that? > https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst I think that AUTOPKGTEST_TMP, etc., is so important that it merits mentioning directly in the document. Not everyone will click a link; put the information in this TUTORIAL document where it cannot be missed. > > $PATH will just contain the default Debian $PATH, again, I think this is > described in Debian policy. The location of the scripts is described in > the spec again. Yes, but I didn't know that the files were installed with "/" as the absolute top-level directory when I began. I recommend conveying that somehow explicitly. Because I only knew that installed binaries could be located using $PATH from the "trivial example" and the bug report that initiated that example, this is what the debian/tests/control file did for utfcheck-1.1-2: Test-Command: cd test && progloc=`which utfcheck` && utfcheck_bindir=`dirname $progloc` ./test-all Now that I know, for example, that my utfcheck program is installed as per the FHS (and not in some sub-tree for example under /var/tmp/ci/sid/usr/bin using $DESTDIR), the debian/tests/control file for utfcheck-1.2-1 (my most recent upload) has simplified the above to Test-Command: cd test && utfcheck_bindir=/usr/bin ./test-all Does this example make it clear what I did not understand from the autopkgtest and CI documentation? So I recommend adding enough to make it clear that absolute file locations are per the FHS and Debian Policy. You can say that in an abbreviated way compared to what I wrote in the HTML file I sent, but not so abbreviated that it might require the kind of experimentation that I did with utfcheck-1.1-2 and -1.2-1 (and I'm still not done; I want to simplify it further by just being able to say "make installcheck", incorporating what I learned into my Makefiles). When I get that far, I intend to write up what I did to get everything to work between GNU Autotools, autopkgtest in the Debian CI environment, and test scripts in the source tree that work on many systems (not just with autopkgtest). > ... > > I copied the two paragraphs that describe AUTOPKGTEST_TMP and > > AUTOPKGTEST_ARCHIVE from > > > > https://people.
Bug#907846: autopkgtest: Please consider additional section for tutorial web page
On Wed, Sep 5, 2018 at 6:46 AM Antonio Terceiro wrote:
>
> On Tue, Sep 04, 2018 at 08:59:12PM +0200, Paul Gevers wrote:
> > Control: reassign -1 debci
> >
> > Dear Paul
> >
> > You're looking at this file:
> > https://salsa.debian.org/ci-team/debci/blob/master/docs/TUTORIAL.md
> >
> > It would be awesome if you could propose changes to that file instead of
> > the generated html file. However, I already have some comments.
>
> Moreover: as is said in the beginning of that tutorial, it is a
> transcription of a talk I gave at Debconf15. What is not said, however,
> is that transcription is incomplete: it stops at example ("tip") 1, and
> the talk goes up to tip 9. Finishing that transcription would be a nice
> contribuition, if anyone out there is listening (hint, hint).
>
> > On 03-09-18 06:42, Paul Hardy wrote:
> > > Please consider adding "The test environment" section (or something
> > > like it) that I added to the autopkgtest tutorial page...
> >
> > Although I appreciate what you try to do here, it rather feels weird, as
> > you are just describing a very standard Debian setup. I really think
> > this is not the place to describe how Debian works and where packages
> > install their files. Policy already does that. So your first paragraph
> > could be "The test environment is a minimalistic standard Debian
> > installation."
> >
> > Your second sentence basically repeats stuff that is in the autopkgtest
> > spec. Maybe we should more clearly link that?
> > https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst
> >
> > $PATH will just contain the default Debian $PATH, again, I think this is
> > described in Debian policy. The location of the scripts is described in
> > the spec again.
>
> I think one point that maybe still didn't get across here is that
> autopkgtest is intended to test packages in their *installed* form. So,
> it should be obvious where stuff is: programs are in $PATH, libraries
> are in the expected locations, services are supposed to be running, etc.
It was obvious to me from the documentation that the CI environment
tested installed packages. What was not obvious, because I do not
know all of the possible virtual environment setups, is that the
packages are not installed in some sub-tree, for example using
$DESTDIR. It seemed that one CI system possibly could have different
sub-trees for sid, testing, etc. Now, from what Martin Pitt said, it
sounds like $DESTDIR will always be null. That is why I did not know
that ordinary executables could just be referenced in /usr/bin.
>
> i.e. the environment in which tests run is a standard Debian system,
> with nothing special, and with -- and only with -- the stuff you said
> needed to be installed for the tests.
>
> [...]
> > Thanks for trying to improve our documentation.
>
> Yes, thanks a lot.
>
> I realize that CI/autopkgtest is a somewhat daunting subject as there
> are several moving parts, and it can be confusing in the beginning. At
> some point it would be very useful to be able to "follow along" people
> who are learning it, capture all the issues that come up and try to
> produce a guide that could make it easier for people doing the same at
> the future.
>
> In fact I think that would make for a cool project for our outreach
> programs.
My life would have been easier if all I attempted was to write tests
that only worked on Debian. I am trying to expand the envelope with
tests that should work on any system where Autotools works. I have
test scripts that work when run from my package "test" directory, and
also with Autotools "check", "distcheck", and "installcheck" targets
from the top-level source directory, except I am not yet at the point
where my test scripts will work with "make installcheck" in the CI
environment on Debian. That is the last piece of the puzzle I need to
solve. At that point, my scripts could be used as examples of how to
write such multi-system test scripts that play nice with Debian if
there is interest in that.
I will do more on this during the weekend but just wanted to give this
initial response.
Thank you for what documentation does exist--there is a lot of it. It
was just the beginning description of what environment someone can
expect with the CI environment that wasn't completely clear to me.
Paul Hardy
Bug#906683: [Piuparts-devel] Bug#906683: piuparts doesn't understand the option --ignore-regexp
Thanks for fixing this so quickly! My package was passing its other checks and has already migrated to testing. Paul Hardy
Bug#907915: developers-reference: language in manual
Package: developers-reference Version: 3.4.20 Severity: wishlist With Debian presenting itself as a distribution suitable for children in educational environments, please consider removing the "f-bombs" in this package. As a fundamental document in Debian, it is something that should be acceptable for school children to read so adding an "offensive" tag to the package will not be enough to remedy the situation. There are three such occurrences: * Section 5.13.2.1 Out-of-date: please find another term for "architectures that don't keep up", and modify the update_out.py mentioned in that section accordingly. * 5.13.2.4 Influence of packaging in testing: same comment; please use another term for such architectures. * 6.3.4 Common errors in changelog entries: please remove the fsck joke by finding a different example for "too many acronyms"--or just make up an example to replace that one. It would be nice to make these changes before the buster freeze if possible, so a cleaned-up version gets into stable as soon as possible. Thank you, Paul Hardy
Bug#906683: piuparts doesn't understand the option --ignore-regexp
This bug also appeared when checking the newly-uploaded package utfcheck-1.2-1, which causes the package to look like it fails piuparts testing: https://piuparts.debian.org/sid/fail/utfcheck_1.2-1.log But piuparts passed on the previous version, utfcheck-1.1-2, without that error. That version entered unstable on 2018-08-11. Thanks, Paul Hardy
Bug#473227: less: Prints UTF-8 Byte order mark
Hi, Just an update. I did not have a released package to check for Byte Order Marks (BOMs) when I wrote my previous message for this bug. Today, however, I uploaded what I think is a reasonably working version of my package utfcheck, which checks an input file to see if it is valid UTF-8. Among other things it will look for and report BOMs anywhere in an input file. You can see it here: https://tracker.debian.org/pkg/utfcheck Start with the latest uploaded version, utfcheck-1.2-1. That has additional information in the man page that was not in previous versions. It prints a summary after reaching end of file on its input, and will even report BOMs that are embedded in the middle of a file--something that a user could easily miss with less. As for the BOM being in text files, programs need to handle that condition correctly. I mentioned in my last message that a UTF-8 BOM has been specifically mentioned as legal Unicode in Table 2.4 of the Unicode Standard from version 5.0 onwards, and actually before then that table was Table 2.3 in version 4.0 of the standard. Someone mentioned elsewhere that LibreOffice includes the BOM in text files, so if nothing else there is no escaping it if a program is to read UTF-8 input from a text file that LibreOffice creates. In version 3.0 of the Unicode Standard, Section 13.6 "Specials" on p. 324 states that "In UTF-8...this sequence can serve as a signature for UTF-8 encoded text where the character set is unmarked." That was published in 2000, almost 20 years ago. I could look it up in older versions of the Unicode Standard too (I have them going back to version 1.0), but I hope there can be general agreement that such a long period of time is long enough for application software to conform. In keeping with the original Unix philosophy that a program should do one thing, and do it well, less should be able to render scrolling text as it is meant to be displayed. That doesn't solve the situation of the UTF-8 BOM though. I hope that utfcheck helps the situation. Thanks, Paul Hardy
Bug#907846: autopkgtest: Please consider additional section for tutorial web page
Package: autopkgtest Version: 5.5 Severity: wishlist Please consider adding "The test environment" section (or something like it) that I added to the autopkgtest tutorial page. It gives an introductory description of the general environment in which a CI test script runs in a way that I have not found elsewhere. The file is small, so I am attaching the whole gzipped file to avoid possible issues with diff on the very long line that is the table of contents list at the start of the file. The original web page is at https://ci.debian.net/doc/file.TUTORIAL.html I copied the two paragraphs that describe AUTOPKGTEST_TMP and AUTOPKGTEST_ARCHIVE from https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html I do not know if what I wrote is accurate, because I do not understand every virtual environment where autopkgtest can run. Resolving my uncertainty will hopefully let me write optimal CI test scripts in the future. What I have written, though, is background information that I did not see anywhere. It would have saved me time when I started trying to use CI testing; hopefully it will save others time. I am submitting this as a new bug rather than modifying bug #906617, because I would like to still have at least prefix=/usr and DESTDIR="" defined if that sounds reasonable. I will add a note to that effect on that bug later. If they are defined like that, I can provide a further patch to add mention of them to this tutorial web page. Thanks, Paul Hardy autopkgtest-tutorial-new.html.gz.sig Description: PGP signature autopkgtest-tutorial-new.html.gz Description: application/gzip
Bug#905686: utfcheck: crash (SIGSEGV) when passing incorrect parameters
The fix is easy, and I expect to have a modified version of the package that works okay uploaded next weekend. I have not created the next version yet though, so I am not tagging this "Pending". I have been seeing if I could improve the package's CI testing setup for the next upload [see bug #906617]. This was my first time using Debian's CI testing and what I did works but is a little rough around the edges. I think I have a better understanding of the CI testing environment now, and should be able to accomplish both things next weekend. Thanks, Paul Hardy
Bug#906617: autopkgtest: Please consider defining directory environment variables
On Sun, Aug 26, 2018 at 11:57 AM Paul Gevers wrote: > On 26-08-18 04:33, Paul Hardy wrote: > > I can suggest additional text as a patch here, re-opening the bug (I > > didn't want to do that before). Then you can accept or reject the > > text I suggest, and close the bug again. > > If you feel more happy with that, please do (please retitle the bug if > you do). Third option is to use your text as starting point and amend it > before acceptance. > ... > Please, don't wait too long. Just update it. If there is stuff wrong > we'll fix it. I'll submit something next weekend. > And just a note about adding autopkgtest to your packages, > you are aware that you can test it on our infrastructure from > experimental? Yes, I had thought of doing that. I was just trying to increase the chance of the next upload's CI testing succeeding with minimal trial-and-error. (My three Autotools-based packages are already passing CI testing, but the way I did things seemed clumsy and I want to simplify things as much as possible.) Thanks, Paul Hardy
Bug#906617: autopkgtest: Please consider defining directory environment variables
Paul, First of all, I would like to say that I know that Martin has file an RFH for autopkgtest because he no longer has the time he used to have for its maintenance, so I sincerely appreciate the detailed reply that he sent to me. On Sat, Aug 25, 2018 at 1:06 PM Paul Gevers wrote: > > Hi Paul, > > On 25-08-18 03:02, Paul Hardy wrote: > ... > Patches to the documentation are always welcome, especially to cover > blind spots in our minds, even if only to get us in the right direction > of what you are really looking for. However, as Martin already > mentioned, try to do this not too specific for make as there are so many > other frameworks. I would have already done that, but felt anything I wrote would have been conjecture. My stumbling block is that I do not understand all the virtual runtime environments that autopkgtest supports. I can suggest additional text as a patch here, re-opening the bug (I didn't want to do that before). Then you can accept or reject the text I suggest, and close the bug again. > Also, I am trying to collect these kind of things and related stuff > (which may be framework specific) here: > https://wiki.debian.org/ContinuousIntegration/AutopkgtestBestPractices > Feel free to add your remarks there. I will be glad to do that once I think I have my facts straight. In the meantime though, with my less than perfect autopkgtest understanding, I will load experimental packages and make sure the CI stuff works first. Thank you, Paul Hardy
Bug#906617: autopkgtest: Please consider defining directory environment variables
Martin,
Thank you for your thoughtful reply. Your email ended up in my spam
folder so I did not see it until now.
I am new to autopkgtest, and feel like I got things working with CI
testing in a convoluted way, that there is probably a cleaner
solution. I looked through everything I could find on Debian, Ubuntu,
and your blog page to sort out an ideal way of using autopkgtest, and
do not think I am there yet...I think there still is some
clarification that could be added to the autopkgtest tutorial.
I DO want to have test scripts in the source tree that are written in
a general enough way to run on more than Debian and even more than
GNU/Linux, rather than writing custom test scripts for debian/tests if
possible. That was part of my motivation. My "make installcheck"
target works on many systems, but with Debian I had to avoid using it.
My "test/test-all" script works when invoked by "make installcheck",
when invoked in the source tree directly, and (now) when invoked from
the Debian CI test infrastructure.
This, for example, is my debian/tests/control file for my utfcheck package:[1]
Test-Command: cd test && progloc=`which utfcheck` &&
utfcheck_bindir=`dirname $progloc` ./test-all
I did that because it was only clear that I could find my program in
$PATH, not that I could count on it being available in /usr/bin as per
the FHS. I thought it might be possible that CI testing could use an
intermediate location in a way I did not know.
My test scripts then invoke "${utfcheck_bindir}/utfcheck"; see for example [2].
If I could just change the control file to be
Test-Command: make installcheck
That certainly would be simpler and more straightforward, but the test
environment would at least need $prefix to be set to override the
/usr/local default. As a not-quite-ideal alternative,
Test-Command: cd test && utfcheck_bindir=/usr/bin ./test-all
would at least be simpler; I just did not know from the autopkgtest
tutorial if it was possible.
That utfcheck package has a Debian bug filed against it. I want to
fix the bug, but I also am hoping to improve some other things related
to Debian packaging when I do. CI testing is one such thing.
On Sun, Aug 19, 2018 at 1:52 PM Martin Pitt wrote:
>
> Hello Paul,
>
> Paul Hardy [2018-08-19 7:44 -0700]:
>> ...
> > By defining a few environment variables (like setting bindir to
> > /usr/bin), it will be more straightforward for people running
> > autopkgtest with Autotools to use a default "make installcheck"
> > target.
>
> Maybe, but I still don't believe this actually makes sense:
>
> * Defining random variables with generic names like $bindir might also
>influence other tests or packages, which makes them work differently than
>they would in a normal OS install.
My thinking was to confine such environment variables to the GNU
standard directory variables; see [3] in the automake manual.
Note that the default value for $prefix with automake is usually
/usr/local. With a Debian build, $prefix is set to /usr for final
installation of course. It was at least $prefix that I was hoping to
have defined in the environment; everything else could fall into place
from that.
> * autopkgtest is meant to be neutral to the test frame work that you use, as
>there are literally hundreds of them. There is no way it could maintain
>support for these.
And regretfully I do not know enough about that to understand the
implications, so I had to ask.
> * This is too magic. Test commands should be very explicit and allow the
>developer to reproduce them step by step in a shell.
>
> * For even `make` to work, you need at least a configured tree, and thus all
>the build dependencies, and most likely even need to build the package.
>autopkgtests should generally avoid that.
>
> * I don't believe that setting static values for these variables even works
>for all automake projects. If they would, why are they even variables?
Most automake projects might not even implement an "installcheck"
target; it is not mandatory (neither is even a "check" target). For
those that do, they would likely be working from the $prefix tree to
locate installed files. I would rather not change the
prefix=/usr/local default, because I would like test scripts and such
work as expected on non-Debian systems also.
> > If we can expect that autopkgtest uses package executables in
> > /usr/bin, package data files in /usr/share/, likewise with
> > other FHS directories, could you update the tutorial page to mention
> > that? Right now there is just an implication on that page from the
> > sample script that the binary executable will be in a directory in
> > $PATH.
>
> Right, as Debian policy mandates that user-execut
Bug#723966: installation-reports: /root directory deleted when re-installing
On Sun, Aug 19, 2018 at 12:57 AM, Bastian Blank wrote: > On Sat, Aug 18, 2018 at 06:52:26PM -0700, Paul Hardy wrote: >> Would it be possible to copy /root someplace temporarily during >> installation, for example to /home/root if /home is an available file >> system or even a RAM-based temporary file system (which won't help >> during a kernel panic)? Then after /root is re-created, files could >> get copied back. > > Sure, you can do copy that yourself. You must not work as root, so > /root does not contain anything useful. If Debian users "must not work as root", then disable root login the way Ubuntu does, but know that then you are going against the way Unix has existed since its beginning. >> Alternatively, if there are files in /root maybe a warning message >> could be printed. > > The whole filesystem is not empty. You asked it to create a new one. > Of cause it will do what you ask. I selected the option for the Debian installer to preserve files, not to wipe out any file system or the root home directory. That is the bug--I specifically did not ask for a new filesystem. Thanks, Paul Hardy
Bug#723966: installation-reports: /root directory deleted when re-installing
On Wed, Mar 5, 2014 at 8:29 AM, Paul Hardy wrote: > Cyril, > > On Tue, Mar 4, 2014 at 7:28 AM, Cyril Brulebois wrote: >> >> Control: retitle -1 installation-reports: /root directory deleted when >> re-installing Would it be possible to copy /root someplace temporarily during installation, for example to /home/root if /home is an available file system or even a RAM-based temporary file system (which won't help during a kernel panic)? Then after /root is re-created, files could get copied back. Alternatively, if there are files in /root maybe a warning message could be printed. I bring this up now in hopes that some change can be made in time for the buster freeze. Thank you, Paul Hardy
Bug#906617: autopkgtest: Please consider defining directory environment variables
Package: autopkgtest
Version: 5.5
Severity: normal
After reading through bug #870654 (requesting a trivial autopkgtest
example) and looking at the example at
https://ci.debian.net/doc/file.TUTORIAL.html, I have gleaned that
commands for autopkgtest are located through the $PATH environment
variable.
If the autopkgtest maintainers would consider defining DESTDIR and the
standard GNU variables for installation directories [see
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html],
then a package built with Autotools ought to be able to perform CI
testing with a debian/tests/control file that only contains the line
make installcheck
as long as the package has a working "make installcheck" implemented.
By supporting invocation of programs as ${DESTDIR}${bindir}/myprog,
that would also remove any ambiguity as to which file is being
executed during CI testing. Similarly for package data file
selection, etc.
Therefore, please consider defining DESTDIR, bindir, etc. in the
autopkgtest environment.
I would be glad to take one of my packages that use Autotools and
experiment with the change for you if you make it.
If autopkgtest already does define DESTDIR, bindir, etc., then please
document that on the tutorial page cited above and I will try it with
my next upload of one of my Autotools-based packages.
You might or might not want to merge this bug with #906125, which also
requests environment variable definition, but this report and that are
different.
Thanks,
Paul Hardy
Bug#883950: Next steps on "[GPL-3+]" proposal
On Wed, Aug 15, 2018 at 6:47 AM, Paul Hardy wrote: > it can be said that the package has made a good faith effort to I meant the "packager", not the "package", anthropomorphism aside! Thanks, Paul Hardy
Bug#883950: Next steps on "[GPL-3+]" proposal
On Tue, Aug 14, 2018 at 10:26 AM, Ian Jackson
wrote:
> Paul Hardy writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"):
>> License: GPL-2
>> file:///usr/share/common-licenses/GPL-2
>
> I'm late to this party, but one of the things that is wrong[1] with
> SPDX is that it implicitly encourages what I would call GPL-v2-only or
> whatever, rather than (say) GPLv2+.
>
> IMO in Debian we should not perpetuate this.
>
> Ian.
>
> [1] politically opposed to my own goals, probably deliberately so on
> the part of the SPDX authors
My intention was not to encourage licensing packages as GPL version
"n" only, but to provide a working example of how to handle that
situation. I suppose you could think of it as the Linux kernel corner
case.
The main suggestion I wanted to make was to use a URI to point to an
uncompressed README file that explains what the "+" implies in GPL-2+,
etc. Some earlier discussion in this bug report concerned how to
inform the reader what the "+" meant. If we provide URIs in
debian/copyright, and those URIs actually exist on the system, I think
it can be said that the package has made a good faith effort to
provide the reader with the full licensing information without full
"License" stanzas. That form would even pass current Lintian checks,
and possibly other checks as well, which was another concern raised in
this bug report.
My post was only a suggestion as a way to handle those issues though,
not a request.
Thanks,
Paul Hardy
Bug#883950: Next steps on "[GPL-3+]" proposal
Just a couple of random thoughts... There are two recurring themes (among others) in this bug report: * How to make sure users know what "+" means, as in "GPL-2+" * How to make sure users know where to find a full license Suppose a tiny README file (uncompressed) is added to /usr/share/common-licenses. It can explain what the "+" in "GPL-2+" etc. mean, and even contain a pointer to the copyright-1.0 document. As for making it easy for a user find the license file, would it be too complicated to use a standard URI in d/copyright? So for example a d/copyright file could contain: License: GPL-2 file:///usr/share/common-licenses/GPL-2 or License: GPL-2+ file:///usr/share/common-licenses/README file:///usr/share/common-licenses/GPL-2 where the README file explains the "+" in "GPL-2+". It would be improbable for a user to see a URI like that and not realize that it points to a specific file location on the system. Thanks, Paul Hardy
Bug#905686: utfcheck: crash (SIGSEGV) when passing incorrect parameters
Thank you for letting me know. The parameter checking code in the original flex source does have a default case that should have caught that. It should list the options and exit with EXIT_FAILURE status. I will look at the flex source and how that was converted into C code, and try to fix it in the next upstream release. Paul Hardy
Bug#905167: debmake-doc: Handling Upstream Autotools Packaging on Debian
On Thu, Aug 2, 2018 at 9:14 AM, Osamu Aoki wrote: > Hi, > > Thank you for your very detailed review. I realized when I wrote it that it was probably _too much_ detail (I tried to keep everything on one screen but went a little past that). I figured I would get all my thoughts down for others to pick and choose what they wanted to use. > On Tue, Jul 31, 2018 at 11:12:12PM -0700, Paul Hardy wrote: >> Package: debmake-doc >> Version: 1.9-1 >> Tags: patch >> >> Section 5.16.1 recommends running autoreconf when building a package > ... > Let's add: > | For compat level 10 or newer, the simple “dh $@” command without > | "--with autoreconf" option can take care all steps 1 to 4, too. > >> That >> brings with it considerations about automake. The default >> "strictness" level of an automake setup is the "gnu" level, which >> requires files AUTHORS, ChangeLog, INSTALL, NEWS, and README along >> with the Makefile.am and configure.ac files that autoreconf will >> expect. That then brings other implications for using such a package >> on Debian. > > Hmmm I had a different thought and intentionally chose "foreign". > >> Elsewhere, the document refers to the GNU Coding Standards, which is >> further reason to make mention of the above files, and which get >> installed and which do not get installed (COPYING and INSTALL) on >> Debian. > > This tutorial is about packaging an upstream source ... not about > creating an upstream source to be uploaded to the GNU project. Yes. I brought up the "gnu" strictness level for automake because the _Guide for Debian Maintainers_ already refers the reader to consult the GNU Coding Standards. It was not with a goal of packaging for the GNU Project. Maybe that is going too far though. > I also find many packages on Debian uses "foreign". Upstream source on > git may not have NEWS and ChangeLog. So making simpler example is good > for entry level document. Another POV I checked is: > > https://autotools.io/automake/options.html#automake.options.flavors > >> I propose that wording like what follows be considered for the end of >> Section 8.9 or 8.11. Both of those examples set the automake > > I think adding a short pointer to remind automake defaults to gnu flavor > may be a good idea around Section 8.9. But I don't think I should > elaborate too much in detail. If we do so, this tutorial get bloated > and reader will lose important things to learn about the Debian > packaging. > > After "configure.ac (v=1.6): " example, add: > > TIP: Without "foreign" strictness level specified in AM_INIT_AUTOMAKE() > as above, automake defaults to "gnu" strictness level requiring several > files in the top-level directory. See "3.2 Strictness" in the automake > document. > > >> The other files besides Makefile.am and configure.ac that Autotools >> expects in the top-level directory (AUTHORS, NEWS, README, and >> ChangeLog) can be installed in /usr/share/doc/. > > This is fair point to be reminded. Place to do is at: > 5.12. Customization of the Debian packaging > > Now: > > * The Debian package build system can be customized through the > debian/rules file (see Section 5.4.3, “Customized debian/rules”). > > * The Debian package installation path etc. can be customized through > the addition of configuration files in the debian/ directory for the > dh_* commands from the debhelper package (see Section 5.11, “Other > debian/*”). > > > Proposed: > > * The Debian package build system can be customized through the > debian/rules file (see Section 5.4.3, “Customized debian/rules”). > > * The Debian package installation path etc. can be customized through > the addition of configuration files such as "package.doc" and > "package.install" in the debian/ directory for the dh_* commands from > the debhelper package (see Section 5.11, “Other debian/*”). > Sounds good. >> Running "autoreconf -ivf" as described in Section 5.16.1 will create >> a new INSTALL file even if one existed.i > > As written there, this is run by the upstream. Well, building in debian/rules with autoreconf will run that too. Actually, I don't know if running automake with "foreign" strictness re-creates INSTALL. I have only tried automake with "gnu" strictness. >> That file will have a copyright, >> as will the GPL or LGPL in the COPYING or COPYING.LESSER file. Therefore, >> list those files in the Files-Exclude field in the first paragraph of >> debian/copyright.
Bug#905167: debmake-doc: Handling Upstream Autotools Packaging on Debian
Package: debmake-doc Version: 1.9-1 Tags: patch Section 5.16.1 recommends running autoreconf when building a package on Debian GNU/Linux, to improve portability to new systems. That brings with it considerations about automake. The default "strictness" level of an automake setup is the "gnu" level, which requires files AUTHORS, ChangeLog, INSTALL, NEWS, and README along with the Makefile.am and configure.ac files that autoreconf will expect. That then brings other implications for using such a package on Debian. Elsewhere, the document refers to the GNU Coding Standards, which is further reason to make mention of the above files, and which get installed and which do not get installed (COPYING and INSTALL) on Debian. I propose that wording like what follows be considered for the end of Section 8.9 or 8.11. Both of those examples set the automake strictness level to "foreign", which is good for a simple example but leaves out some details that could help someone new with Debian packaging. I tried to capture the major considerations for packages that follow GNU standards, and think something along these lines would help: [begin insert] The line AM_INIT_AUTOMAKE([foreign]) in configure.ac above tells automake to use a "foreign" strictness level, which has loose requirements for what files are in a package. The default strictness level for automake is "gnu", which expects the following files in the top-level directory: AUTHORS, INSTALL, NEWS, README, ChangeLog, and either COPYING (with a copy of a GPL license) or COPYING.LESSER (with a copy of a LGPL license). If you are building such a package, Section 5.16.1 [Autotools] of this guide recommends invoking autoreconf in debian/rules to provide better support for porting to new architectures, compared to just running "./configure && make". If you intend to run autoreconf on a package with automake set to a strictness level of "gnu", automake will complain if the files it expects in the top-level directory are not present. In this case the INSTALL and COPYING (or COPYING.LESSER) files must be present in the source directory. However, they are not installed on Debian systems because Debian uses its own package manager for installation, and keeps copies of common licenses in /usr/share/common-licenses. The other files besides Makefile.am and configure.ac that Autotools expects in the top-level directory (AUTHORS, NEWS, README, and ChangeLog) can be installed in /usr/share/doc/. This can be done by listing those files in debian/doc. If you keep any Autotools-generated files in the Debian package, make sure that those files have their copyright and license information captured in the debian/copyright file. Their copyright notices and license terms differ slightly, so you will have to check every one. The GNU Project standard practice is to leave all such files in place if a "make distclean" leaves them, so asking upstream to remove them is probably not the correct solution. Running "autoreconf -ivf" as described in Section 5.16.1 will create a new INSTALL file even if one existed. That file will have a copyright, as will the GPL or LGPL in the COPYING or COPYING.LESSER file. Therefore, list those files in the Files-Exclude field in the first paragraph of debian/copyright. Also list any files that "autoreconf -ivf" creates but that remain following a "make distclean" in the Files-Exclude field, because autoreconf will recreate those files. Some maintainer discretion is allowed to leave a config.h file that should not change, etc. Apart from those files, the only other files that must exist with the "gnu" automake strictness level to run autoreconf in the top-level directory are Makefile.am and configure.ac. One of the standard "make" targets that automake creates is "distcheck". That builds a copy of the package in a staging directory by defining the DESTDIR variable, then creates a distribution tar file of the package from the newly-built copy, and finally tries building from that tar file a second time along with running various checks on the final result (see the GNU Automake manual for further details). It is advisable if you are using GNU Autotools to ensure that "make distcheck" succeeds on the upstream package before attempting to create a debianized version. If the upstream package fails a "make distcheck" with Autotools, it will probably have issues on Debian. [end insert] Thanks, Paul Hardy
Bug#904943: ITP: utfcheck -- check validity of UTF-8 and ASCII files
Package: wnpp Severity: wishlist Owner: "Paul Hardy" Version: 1.0 Upstream Author: Paul Hardy URL: http://unifoundry.com/utfcheck License: GPL 2+ Programming Language: flex Description: check validity of UTF-8 and ASCII files The utfcheck program examines a text file and prints a summary of what the file contains: ASCII, UTF-8, UTF-16 (either big-endian or little-endian based on an initial Byte Order Mark), or binary data. ASCII and UTF-8 files are processed further; UTF-16 and binary files are not. For a UTF-8 file, the summary includes whether or not the file begins with the Unicode Byte Order Mark (U+FEFF). Any following data encountered that is not well-formed ASCII or UTF-8 Unicode is considered to be binary data; upon reading such data the input file is considered not to be a proper text file and the program exits with an error status. The utfcheck program returns an exit status of EXIT_SUCCESS if the text file was well-formed, and EXIT_FAILURE otherwise. Thanks, Paul Hardy
Bug#473227: less displaying BOM
> BOM is a piece of binary junk that most programs don't accept I agree that it does not make sense philosophically for a "byte order mark" to be in a file encoded in a way that is byte-order independent. The Unicode Standard does not recommend its use in a UTF-8 file because it is not necessary. However, it is a bug for programs not to accept the BOM at the start of a UTF-8 file, because the Unicode Standard explicitly allows its presence in a UTF-8 file as a byte order mark. See Table 2.4, "The Seven Unicode Encoding Schemes", which has been in the Unicode Standard for more than a decade (Table 2.4 was in Unicode version 5.0 and it is still in Unicode version 11.0, released in June 2018). I use "od" (for example, "od -t c my-file | head -1" or "od -t x1 my-file | head -1") to see if a file starts with a BOM, or have a program I wrote check for it. I would not trust "less" or some other program besides "od" to display it. I think "less" should display printable characters the way they are expected to be viewed unless viewing a file in raw mode. The formal rendering of the BOM is as a "zero-width no-break space". That was its original purpose as a word joiner, and that is how the Unicode Standard says it still should be rendered for backward-compatibility with earlier versions of Unicode (see Unicode Standard 11.0, Section 23.2, Layout Controls). Even in raw mode, I still would not trust less to find out if a file started with a BOM--I use od. Thanks, Paul Hardy
Bug#904217: debmake: typos in man page
Package: debmake
Version: 4.3.0
Severity: minor
Tags: patch
Here are patches for the debmake man page. These could also be
applied to the debmake man page that appears at the end of the "Guide
for Debian Maintainers" document and to the description of the
"-x[0-4]" flags in the main body of that guide.
The first change is "program to make the Debian source package" -->
"program to make a Debian source package"; it can also be changed in
the Description field in debian/control.
It looks like this man page might have been created from Docbook. If
so, I do not know how to apply the typographic changes to Docbook
source, but I will describe them below.
Ellipses (three periods in a row) look better in troff/groff typeset
output if there is more space between each period than ordinarily
surrounds a period. In nroff/troff, the traditional way of
accomplishing this has been to put a "thick space" between the periods
by typing "\|.\|.\|." instead of "...". I made those changes.
There were also instances of "\&.\&.\&.". If what was intended was a
thin space, that would be "\^" and not "\&". "\&" can do weird things
with alignment if you don't know how to use it, and it appeared
throughout the file. The file seems to have been generated by a
Docbook style sheet, so there might be a bug in whatever style sheet
was used.
In nroff, if in the middle of a line you temporarily switch to a
different font style and then switch back to what you were using, it
is preferable to use the "\fP" markup to return to the previous font
style ("P" is for "previous", as in the previous font style). For
example, you can change "\fB-x0\fR" to "\fB-x0\fP". See where I did
that as I mention in the next paragraph...
The "-x[0-4]" options had ",," (two commas) to represent a quote mark,
to mean that everything in the preceding line applied. The symbol for
a quote is locale-dependent though. For example, in the U.S. we would
use '' instead of ,,. I added "same as \fB-x[0-3]\fP"... to avoid the
whole quote/locale issue (you can look at the result to see what I
did.
For the "-y" option, where you say doubled option = "force no", does
that mean "-y -y" will force a "no" response? That was the one part I
wasn't sure about.
In the CAVEAT section, it says: "You must remove or edit such comment
lines...". I changed that to "You should remove or edit such comment
lines..." because I think "must" would imply a policy violation.
"Should" implies a recommendation. If it truly is a policy violation,
then I need to remove or edit the comments in my debian/watch files.
:-)
You might want to change the copyright from "2014-2015" to
"2014-2018", but I didn't change that in case "2014-2018" is what you
intended.
I am also attaching the PDFs, so you can see the before and after
results. I created them with, for example:
groff debmake.1 > debmake.1.ps
ps2pdf debmake.1.ps
Please let me know if you have any questions or comments.
Thank you,
Paul Hardy
debmake.1.patch.sig
Description: PGP signature
--- debmake.1 2018-07-10 06:11:11.0 -0700
+++ debmake-new.1 2018-07-21 12:36:59.495053451 -0700
@@ -28,13 +28,13 @@
.\" * MAIN CONTENT STARTS HERE *
.\" -
.SH "NAME"
-debmake \- program to make the Debian source package
+debmake \- program to make a Debian source package
.SH "SYNOPSIS"
.sp
-\fBdebmake\fR [\fB\-h\fR] [\fB\-c\fR | \fB\-k\fR] [\fB\-n\fR | \fB\-a\fR \fIpackage\-version\fR\fB\&.orig\&.tar\&.gz\fR | \fB\-d\fR | \fB\-t\fR ] [\fB\-p\fR \fIpackage\fR] [\fB\-u\fR \fIversion\fR] [\fB\-r\fR \fIrevision\fR] [\fB\-z\fR \fIextension\fR] [\fB\-b\fR "\fIbinarypackage\fR\fI, \&...\fR]" [\fB\-e\fR \fIfoo@example\&.org\fR] [\fB\-f\fR "\fIfirstname lastname\fR"] [\fB\-i\fR "\fIbuildtool\fR" | \fB\-j\fR] [\fB\-l\fR \fIlicense_file\fR] [\fB\-m\fR] [\fB\-o\fR \fIfile\fR] [\fB\-q\fR] [\fB\-s\fR] [\fB\-v\fR] [\fB\-w\fR "\fIaddon, \&...\fR"] [\fB\-x\fR [01234]] [\fB\-y\fR] [\fB\-L\fR] [\fB\-P\fR] [\fB\-T\fR]
+\fBdebmake\fR [\fB\-h\fR] [\fB\-c\fR | \fB\-k\fR] [\fB\-n\fR | \fB\-a\fR \fIpackage\-version\fR\fB\&.orig\&.tar\&.gz\fR | \fB\-d\fR | \fB\-t\fR ] [\fB\-p\fR \fIpackage\fR] [\fB\-u\fR \fIversion\fR] [\fB\-r\fR \fIrevision\fR] [\fB\-z\fR \fIextension\fR] [\fB\-b\fR "\fIbinarypackage\fR\fI, \&\|.\|.\|.\fR]" [\fB\-e\fR \fIfoo@example\&.org\fR] [\fB\-f\fR "\fIfirstname lastname\fR"] [\fB\-i\fR "\fIbuildtool\fR" | \fB\-j\fR] [\fB\-l\fR \fIlicense_file\fR] [\fB\-m\fR] [\fB\-o\fR \fIfile\fR] [\fB\-q\fR]
Bug#904202: debian-keyring: minor typos in README
Package: debian-keyring Version: 2018.06.24 Severity: minor Tags: patch Dear debian-keyring Maintianers, Attached are a few typo corrections for the README file. Thanks, Paul Hardy README.patch.sig Description: PGP signature --- README 2017-05-11 03:47:43.0 -0700 +++ README.new 2018-07-21 06:19:05.662372908 -0700 @@ -20,7 +20,7 @@ credentials in OpenPGP certificate formats, aggregated into "keyrings", which are just concatenated files of OpenPGP certificates. -These keyrings have a suffix of .gpg, refelcting our use of GnuPG (the +These keyrings have a suffix of .gpg, reflecting our use of GnuPG (the GNU Privacy Guard), the most widely-used free software implementation of OpenPGP. @@ -32,7 +32,7 @@ Getting debian-keyring.gpg -- -The current versions of debian-keyring.gpg is always available via +The current version of debian-keyring.gpg is always available via rsync from keyring.debian.org (module keyrings). There is also a (possibly slightly out-of-date) version available on @@ -64,7 +64,7 @@ personal keyring. You can use "gpg --no-options --import" to force GPG to ignore gpg.conf and import keys to your personal keyring only. -It also possible to use public keyservers on the net directly. This +It is also possible to use public keyservers on the net directly. This requires that you have a working internet connection. Add a line to your ~/.gnupg/gpg.conf[1] file such as: @@ -109,7 +109,7 @@ helps to expand and strengthen the OpenPGP web of trust. Do *NOT* certify other people's key unless you have met that person -face to face in real life and are have verified that the person is who +face to face in real life and have verified that the person is who they say they are. One common way people can verify identity is to ask for a strong, unforgeable form of government-issued ID that they know how to check (e.g. passport, driver's license). @@ -131,12 +131,12 @@ Updating your key(s) -There is a keyserver running on keyring.debian.org, for any updates of +There is a keyserver running on keyring.debian.org; for any updates of existing keys please send them there, e.g: $ gpg --keyserver=keyring.debian.org --send-keys 0x0123ABCD -To add a new key or remove an existing ones, please send mail to +To add a new key or remove an existing one, please send mail to keyr...@rt.debian.org making sure to include the words "Debian RT" somewhere in the subject line. @@ -190,7 +190,7 @@ Darren Stalder , Norbert Veber and Martin Michlmayr . -Many thanks to Brendan O'Dea who setup and wrote +Many thanks to Brendan O'Dea who set up and wrote support scripts for the keyserver on keyring.debian.org.
Bug#904174: ITP: unibetacode -- convert classical Greek and Coptic between Beta Code and Unicode
Package: wnpp Severity: wishlist Owner: "Paul Hardy" Version: 1.0 Upstream Author: Paul Hardy URL: http://unifoundry.com/unibetacode License: GPL 2+, GFDL 1.3+ Programming Language: flex Description: convert classical Greek and Coptic between Beta Code and Unicode The unibetacode package contains two utilities primarily designed for ASCII transliteration of classical Greek: beta2uni converts Beta Code text to UTF-8 Unicode, and uni2beta converts text from UTF-8 Unicode to Beta Code. A third utility, unibetaprep, converts special codes for other characters (such as Byzantine musical symbols) into four- to six-digit Unicode code points. Beta Code is an ASCII-only encoding scheme created in the 1970s as an efficient, intuitive digital input method for classical Greek. It provides an easy way to enter classical Greek on a plain ASCII keyboard for conversion to UTF-8 Unicode text. This package implements a subset of Beta Code as specified by the Thesaurus Linguae Graecae (TLG) Project at the University of California, Irvine. The unibetacode package also is compatible with the Beta Code implementation of the Perseus Digital Library of Tufts University and other online repositories of classical Greek. TLG Coptic support only includes the basic alphabet plus the jinma (grave) accent. TLG Hebrew support only covers the basic alphabet, aleph (U+05D0) through tav (U+05EA). To this base, unibetacode adds full Unicode coverage. The unibetacode(5) man page describes the Beta Code file format in detail. Files in the examples directory provide sample encodings and test data.
Bug#903804: debmake-doc: Proofreading Comments
By pure coincidence, the Wikipedia page on gettext shows that gettext will correctly translate "My name is %s" into "Je m'appelle %s" in French. So changing the po example on p. 122 of debmake-doc.en.pdf from msgid "Hello, I am %s!\n" to msgid "Hello, my name is %s!\n" should fix that. See this excerpt at https://en.wikipedia.org/wiki/Gettext #: src/name.c:36 msgid "My name is %s.\n" msgstr "Je m'appelle %s.\n" Paul Hardy
Bug#752993: automake: configure does not parse variables to make foo.Po files
As a follow-up to my earlier "fixed-upstream" tag based on the upstream maintainer's belief, I tested my package with automake 1.16.1 (the latest upstream version). It did fix this bug that automake 1.15 manifested in my case. I was able to get around the bug in automake 1.15, so it does not affect me at this moment. I had to re-do how I implemented "make check" targets to circumvent it (long story that would involve poring over generated Makefiles). But I it would be nice if automake 1.16.x made it into buster--the bug was quite a stumbling block for me when I ran into it. Thanks, Paul Hardy
Bug#868496: debmake-doc: Please Reference Debian Fonts
Osamu, Here is a sample, simple font package that might help you document font packaging in debmake-doc. I needed to work through creating a debian/copyright file in the new format, etc. I didn't want to send something that might not be useful as an example. You can pick and choose what you want from this. I used GPL 2+ as the license; if you want a different license for debmake-doc, let me know. In creating this, I placed a COPYING file and an INSTALL file in the original (fake upstream) tarball. They do not get installed of course, because Debian handles them in different ways. But those are standard files in a GNU-style package distribution. I also created a tiny NEWS file and README file. Those are copied, and are listed in debian/docs. I also used an override for autopkgtest (see debian/src/lintian-overrides). With the package only consisting of one TrueType font (that only contains one letter!) and some text files, I don't know that autopkgtest can test anything. Please go ahead and modify this any way you want if it will help make debmake-doc clearer. Let me know if you have any questions. Thanks, Paul Hardy -BEGIN PGP SIGNATURE- iQIzBAABCgAdFiEEldLpq4dA2ARjh/0VGgkiex9DWjMFAltLsVUACgkQGgkiex9D WjNnog//ZbddaD+P2ZwVUIRxuZ7nwtl5HbxipmFFmFft7QBs80HSoHH8X8h8T5MO b3+Bb9FmJ4S8zCA7Ne0timdQnEglckmHNc5HgF2GMapmV5jHglvTBGJITnk+eYcR yz68HaYoH7Hs7Z5ynRzL0bLzb8320dI/aIMZm0nyA3Ayjt3zutiA2iXsQtP4k7o7 ldZrtq/x3ur2//4boQcWEDWoXg0LMN8V86FESCssM0eSO1HsJQHyrjcAU1JhlYa3 wKVOl9LuieDXzEXWgEPIh/YO9IMsvhAyxG7R3dAZ3M/+6DEkJQ4gSxnGolN03fI/ Zp5/zx0wVG7WzSEuBhGOYJenVowfMEN8vORuTFUHJitv9FgDf244kMxzGiMtJpj8 qydAoGB1h7ZHfj+cfyxfmV4D7YJUyaoLdYySelTUhlcCpRjTAoGTCRbtHxcwaEao iine0xcTWd6GYc1O2z7xrkpwi1iN6KdVK6wKU9Iev/U7j5hm8hh0bIWCkhJxsvpK JrbWyvzEMlGslPGCGj59j8IAtGS1rFL0nb1FiuVF5MNGAkjE6qw784+B5EB23rf+ yHaQQp47R8WpAEw/2TvWUJOesZXNIzO88a1LJ1fDuGIo/J9ZNVBME9/3LTb3d3y/ UMrhGWDoYnuNE133fDigx06PVJpa4Dc0ZtwAgpTOfYu0IR5FKDI= =2hvL -END PGP SIGNATURE- fonts-justa_1.0-1.debian.tar.gz.sig Description: PGP signature fonts-justa_1.0-1.debian.tar.gz Description: application/gzip fonts-justa_1.0.orig.tar.gz Description: application/gzip
Bug#903805: debmake-doc: Autopkgtest Comment and help2man Comment
I just ran across this link by Martin Pitt about adt being deprecated, with adt-run being replaced by autopkgtest in unstable: https://piware.de/2016/06/autopkgtest-4-0-simplified-cli-deprecating-adt/ That information might give you content for the new autopkgtest process. Thanks, Paul Hardy
Bug#903681: psf-unifont: Should not Depend on bdf2psf
Jacob, On Thu, Jul 12, 2018 at 5:59 PM, Jacob Adams wrote: > Package: psf-unifont > Version: 1:11.0.01-1 > Severity: minor > > While this package clearly needs to Build-Depend on bdf2psf, I fail to > see a clear reason for it to Depend on it. The font is perfectly usable > without bdf2psf. Thanks for noticing this. I am preparing a new Unifont release and have already made that change, as well as the one I just reported in bug #930833 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903833). I figured I'd report that before someone else did. Take care, Paul Hardy
Bug#903833: ttf-unifont: does not need to Depend on xfonts-utils
Package: ttf-unifont Version: 1:11.0.01-1 Severity: minor The package ttf-unifont is a TrueType font. TrueType fonts do not need a Depends entry for xfonts-utils. This will be fixed in the next upcoming Unifont release. Thanks, Paul Hardy
Bug#903805: Acknowledgement (debmake-doc: Autopkgtest Comment and help2man Comment)
I meant to say typing "adt-run --version" gives the warning message about it being deprecated, not just typing "adt-run" by itself. Thanks, Paul Hardy
Bug#903805: debmake-doc: Autopkgtest Comment and help2man Comment
Package: debmake-doc Version: 1.9-1 Severity: wishlist Sections 5.11 and 5.22 mention the Autopkgtest command "adt-run". Typing "adt-run" in Debian stable gives this output as its first line: adt-run: WARNING: "adt-run" is deprecated, please use "autopkgtest" (see manpage) It would be good to have debmake-doc updated to reflect the latest autopkgtest practices, whatever they are (I am not knowledgeable on that). Also, Section 5.11 in the "manpage.*" list item mentions two starting points for creating man pages: manpage.asciidoc and manpage.1. This guide could also mention the GNU help2man package, which takes the output of a program's "--help" and "--version" options to create a simple man page. help2man is available as a Debian package. Thanks, Paul Hardy
Bug#903804: debmake-doc: Proofreading Comments
Package: debmake-doc
Version: 1.9-1
Tags: patch
Attached are proofreading comments on the files in the "asciidoc"
directory in this package. Please let me know if you have any
questions.
Other comments:
* In the debian/control file of many template examples, "demonstrate
the Debian packaging" should just be "demonstrate Debian packaging".
* In the po example you give for French, in file
debhello-3.3/po/fr.po, the translation of "Hello, I am..." is
"Bonjour, je suis...". Ask a native French speaker, but the French I
learned in school was that the correct way of saying "I am so-and-so"
in French is "je m'appelle" ("I call myself"), not "je suis". I don't
know if that is a bug in gettext or just in the debmake-doc package.
* I will submit proofreading comments for the debmake(1) man page
separately later.
Thanks,
Paul Hardy
asciidoc.patch.gz
Description: GNU Zip compressed data
Bug#903791: ITP: utf8gen -- convert Unicode hexadecimal code points to UTF-8
Package: wnpp Severity: wishlist Owner: "Paul Hardy" Version: 1.0 Upstream Author: Paul Hardy URL: http://unifoundry.com/utf8gen/ License: GPL 2+, GFDL 1.3+ Programming Language: C Description: convert ASCII hexadecimal Unicode code points to UTF-8 The utf8gen package contains one program, utf8gen, which reads hexadecimal numbers interpreted as Unicode code points and produces formatted output. The numbers are provided one per line. Each number is optionally followed by a space plus miscellaneous text. The output is specified by providing printf(3)-style format strings on the command line. This provides the flexibility to print UTF-8 byte values in any desired base, echo the input value formatted as a comment in any desired programming language, or even to provide HTML-like table entries. Optional miscellaneous text on each input line can be copied to the output. The suggested additional packages allow converting the man page to PDF and converting the Texinfo user guide to PDF and/or HTML. -- Paul Hardy
Bug#902833: doc-base: typos in manual
Source: doc-base Version: 0.10.8 Tags: patch There are some typos in the doc-base HTML manual. I have made changes to the XML source file, doc-base-0.10.8/doc/doc-base.xml. A patch file is attached. Some notes: - "ham radio" -- "ham" is not capitalized (I am a radio ham and vouch for this one). - "Texinfo" -- GNU documentation capitalizes this when describing the system, not the program itself or the package name. - Usually punctuation is set in the same type style as the text it follows, but I did not change punctuation that immediately followed "emphasis" tags. If you want to change those instances, I can send a patch for them also. - Usually in English when two complete sentences are combined into one, they are separated by a semicolon, not a comma. See for example https://en.wikipedia.org/wiki/Comma_splice. I use them myself sometimes, but generally a semicolon is better. Also, you might or might not want to mention in the introduction for section 2.3 that control files are ordinarily stored in the debian directory under package-name.doc-base. Thanks, Paul Hardy doc-base.xml.patch Description: Binary data
Bug#843207: ITP: man2texi -- man page to texinfo file converter
Status Update: Nelson Beebe has published his latest book, _The Mathematical-Function Computation Handbook: Programming Using the MathCW Portable Software Library,_ and is working on completing the free software distribution that will accompany the book. That monumental effort has taken the majority of his time over the past several years. He has sent me a version of man2texi that still needs some work before it can be released. Some issues with texinfo need to be resolved. I have not looked at this yet but (now that Unifont 11.0.01 is released) plan to look at it soon. Thanks, Paul Hardy
Bug#875572: unifont FTCBFS: many reasons
On Tue, Oct 31, 2017 at 1:52 PM, Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> wrote: > Control: tags -1 + pending I just want to note that this has not fallen off my radar. I have already applied the patch in the upcoming version. I am hoping to provide a resolution to over 40 bug reports that someone has made against Unifont over the past few months on Savannah: https://savannah.gnu.org/bugs/?group=unifont I hope to get through most of those over the next month, and then provide an updated version for Debian. I had worked through many more for the current Unifont release. This Debian bug was mentioned as being low priority, so I would like to submit the next release with as many updates as possible versus a "micro-release". I also recently helped the HarfBuzz maintainer identify a HarfBuzz bug. HarfBuzz renders glyphs for Pango, which in turn renders text for GNOME. I was not sure if there was something deep down in Unifont's structure that I would have to update, but that turns out not to be the case: https://bugzilla.gnome.org/show_bug.cgi?id=787284 If anyone does need this patch applied urgently, let me know and I will be able to fix it the following weekend. Otherwise, I am planning for a Unifont update with a lot of glyph fixes. Thank you, Paul Hardy
Bug#875572: unifont FTCBFS: many reasons
Greetings Manuel, On Tue, Oct 31, 2017 at 1:52 PM, Manuel A. Fernandez Montecelo < manuel.montez...@gmail.com> wrote: > Control: tags -1 + pending > > Hi Paul, > > 2017-09-13 05:35 Paul Hardy: > >> Helmut, >> >> ... >> I am preparing another upload, Unifont 10.0.07. I have added your >> changes. I also changed "install" to "$(INSTALL)" in src/Makefile so >> someone can redefine it on the command line to "install -s" if they >> want, for non-Debian builds. >> > > Marking as +pending accordingly. > > Is it okay with you if I wait until Sunday, October 1st. > > > 1st of November is here... so perhaps it can proceed now -- no rush > though, there's nothing critical depending on it AFAIK. It sounded like Helmut thought there was no rush with this, so I have updated the Makefile in question and made other changes to it ( with testing from the top-level Makefile, etc.). But I am also going over a number of other proposed changes and hoped to release many changes in one release. I am also trying to finish something on another free software project right now that is urgent. If anyone considers this urgent, I can perform an update during the next weekend. Otherwise, I plan to have a release with many changes in December. In the meantime, thank you for marking this as "pending"; it does reflect the current state. Sincerely, Paul Hardy
Bug#878033: developers-reference: typos, etc.
On Mon, Oct 9, 2017 at 12:56 AM, Adam D. Barratt <a...@adam-barratt.org.uk> wrote: > On 2017-10-08 23:51, Paul Hardy wrote: >> >> Section 5.13.2: low priority packages no longer wait 10 days to >> migrate to testing; they wait 5 days now. If this is a permanent >> change, I would update this section. > > > What makes you think that? The live configuration for britney has: > > MINDAYS_LOW = 10 > MINDAYS_MEDIUM= 5 > MINDAYS_HIGH = 2 > > and from excuses > > wdm (1.28-20 to 1.28-21) > Migration status: WAITING: Waiting for test results, another package or > too young (no action required now - check later) > Maintainer: Axel Beckert > Too young, only 0 of 10 days old > > and indeed > > +wdm (1.28-21) unstable; urgency=low I gave unifont 1:10.0.04-1 an urgency of low, and yet it migrated to testing after 5 days. That was in July. I have only used "urgency=medium" since then. It sounds like whatever happened was temporary. Thanks, Paul Hardy
Bug#878033: developers-reference: typos, etc.
Package: developers-reference Version: 3.4.18 Severity: wishlist Tags: patch -- The proposed patches fix typos and make other suggested changes. I made these by hand on a printout of the PDF version, so they reflect things I saw in that copy. I did not make changes related to back-quotes or the ` character disappearing in the PDF output. I think that will take work in the xslt files, but that will have to wait for now. One typographical change I suggest making is changing "..." to the Unicode horizontal ellipsis character, U+2026, HTML entity "". The ellipsis spreads out the periods more than if three periods are just typed together. I don't know what the implications will be for all the various output formats though so I did not introduce that change. Comma splices generally replace the comma with a semicolon (I think I did that in all cases). The phrase "top-level" should be "top level" when used as a noun, not an adjective; likewise, "third-parties" should be "third parties" as a noun. Some acronyms were spelled out the first time they were used (DSA, API, and ABI). There were a couple instances of "e.g. a, b, c, etc." or "like a, b, c, etc."; in such a case, generally "e.g."/"like" or "etc." should be used, but not both. I retained the "etc.". I made "which" vs. "that" changes in several places. I modified common.ent to reflect that there are 10 (not 11) supported architectures, and changed the names of stable, oldstable, etc. in ENTITY declarations. Note that in Section 5.4 concerning the first time a package is uploaded, I changed "should" to "must" concerning including the original source file. I believe this is correct, because otherwise the original source file is not part of the package. Other things I observed but did not change: Section 5.13.2: low priority packages no longer wait 10 days to migrate to testing; they wait 5 days now. If this is a permanent change, I would update this section. Section 5.13.3: recommend removing the ending punctuation in the list for all elements except the final "." on the last element. Section 6.7.8.1: tar can read a ".tar.gz" file directly without using zcat; consider rewriting this line to just use tar. Thank you, Paul Hardy developers-reference-3.4.18.patches Description: Binary data
Bug#868496: Policy and dh_foo etc.
Osamu, On Sun, Sep 17, 2017 at 1:53 AM, Osamu Aoki <aoki.os...@gmail.com> wrote: > > > I didn't add even an packaging example since I can't make a small > TTF/OTF font to be included in this package. If you have EXTREMELY > small font (Maybe having only "A" in it with example packaging as MIT > license, I will add it to example. Please send me such ;-) Thus more > info. I thought I would try to learn how to create a letter directly in raw SVG code, then figure out how to bring that into FontForge to create a TrueType font. I had never done that before, so it was a bit of a fun adventure. I created a letter 'a' shape using SVG (starting with the SVG header in an example on Mozilla's site, then drawing a circle and a line). Then I imported that into FontForge and used that letter to create a TrueType font. It turned out not to be too hard, but this is all I have time to do right now. I am attaching the original "a.svg" file I created, which you can view in Firefox or probably other web browsers as well. You can also look at it with a plain text editor. I had to remove the fill="transparent" circle attribute for FontForge to accept that file. The "Justa.ttf" file contains just the letter 'a' (and maybe some other things that FontForge adds on its own). You can give these files any license you want. [I think we can remove Sean from future emails on this bug, because it is no longer against debian-policy.] Thank you, Paul Hardy Justa.ttf Description: application/font-ttf
Bug#875572: unifont FTCBFS: many reasons
Helmut, On Tue, Sep 12, 2017 at 3:33 AM, Helmut Grohne <hel...@subdivi.de> wrote: > > unifont fails to cross build from source, for a pile of reasons, all of > which are fixed in the attached patch. After applying it, unifont cross > builds successfully. Thank you for explaining this issue in such detail, and for taking the time to put together a patch. I am preparing another upload, Unifont 10.0.07. I have added your changes. I also changed "install" to "$(INSTALL)" in src/Makefile so someone can redefine it on the command line to "install -s" if they want, for non-Debian builds. Is it okay with you if I wait until Sunday, October 1st to perform this upload? I will be away from home the weekend after next without a computer; I would rather not perform an upload right before being away from home. Thanks again, Paul Hardy
Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more
Chris, On Sat, Sep 2, 2017 at 1:41 PM, Chris Lamb <la...@debian.org> wrote: > Paul, > >> Oh, I see. Personally, my only concern was that a lintian error would >> prevent an uploaded, released package from migrating to testing. > > Hm? Lintian has no effect on migrations from unstable to testing. I never knew that, mainly because I never tried getting a package uploaded in that state. The whole thing caught me off guard. > ... > See #870722. This was fixed in 4th August in: > > > https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=126157380dc0eba302f3d476b1cffc13f968c207 That is great. The next lintian release should be able to close this bug then, unless Stefan disagrees. Thank you! Paul Hardy
Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more
Chris, On Fri, Sep 1, 2017 at 11:08 PM, Chris Lamb <la...@debian.org> wrote: > Hi Paul, > >> > Can you think of another way your particular versions could be >> > detected? >> >> Sorry, I don't understand what you mean by "versions". I do use a >> watch file for Unifont > > Nothing to do with watchfiles, but rather I want to work out somehow > we can not emit this tag until you are ready to release and a > signature would actually exist. Oh, I see. Personally, my only concern was that a lintian error would prevent an uploaded, released package from migrating to testing. I did not think it should be a lintian error, because not having the file does not violate Debian Policy. I think a warning would be a better severity level. I think having lintian give a warning for a missing ".orig.tar.*.asc" file is appropriate even for UNRELEASED, so the package maintainer realizes the omission as early as possible and can prioritize adding it (or even severity "Info" in cases where it is not known if the upstream tarball has a signature). An exception, as you mentioned, would be a dfsg version of an upstream tarball. However, I have modified my building procedure so that now I do create a ".asc" signature file from my GNU ".sig" file before pdebuild starts. So I have circumvented the whole issue, but that doesn't solve it for others. Thank you, Paul Hardy
Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more
Chris, On Fri, Sep 1, 2017 at 8:11 AM, Chris Lamb <la...@debian.org> wrote: > > Can you think of another way your particular versions could be > detected? Sorry, I don't understand what you mean by "versions". I do use a watch file for Unifont; here is the heart of it: opts=pgpsigurlmangle=s/$/.sig/ \ ftp://ftp.gnu.org/gnu/unifont/unifont-([\d\.]+)/unifont-([\d\.]+)\.tar\.gz The upstream signature file will always be a ".sig" binary file generated with "gpg -b", because that is what is required to upload the tarball to the GNU Project's server. With my latest Debian Unifont package though, I re-encoded the original ".sig" file to an ASCII-armored ".asc" file. I used a method that Guillem Jover posted in the debian-policy thread that I started, cited in my previous message for this bug report. It was either that or have lintian generate an error--or override the error, which I did not want to do. Thanks, Paul Hardy
Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more
Chris, On Fri, Sep 1, 2017 at 1:55 AM, Chris Lamb <la...@debian.org> wrote: > > Hey Stefan and Paul, > > > orig-tarball-missing-upstream-signature error breaks rebuilding > > existing packages > > The next version of Lintian will ignore "repacked" tarballs - ones > that contain "dfsg" in their version. That certainly sounds reasonable, because the "dfsg" version is no longer the original version for those cases. > > Perhaps we could also ignore "UNRELEASED" in the distribution? Or > is there something else we could check for in the version...? Personally, I run pdebuild with a hook for the unstable version of lintian, and separately run the testing version of lintian, all the time on an UNRELEASED distribution during development. I only change UNRELEASED to unstable at the very end to finalize a package for uploading, after performing all checks. I am probably not the only one to do that. So I would still let lintian treat an UNRELEASED distribution as if it were in final form. As for a straightforward acceptance of GNU Project ".sig" files for packages as I requested previously in this bug report, later discussion on the debian-policy mailing list has shown preference for ".asc"-only files, with ".sig" files being converted to ".asc": https://lists.debian.org/debian-policy/2017/08/msg00201.html There is no outright ban on binary ".sig" files, but that discussion is leaning towards ".asc"-only signatures. Of course, Debian Policy 4.1.0 also just added mention of debian/upstream/signing-key.asc. Thank you, Paul Hardy
Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more
I second the request that this lintian check just be a warning, not an error. Please also accept binary signature files--and I realize more than just lintian will have to change to support that. The GNU Project's files are signed with "gpg -b" to produce a binary ".sig" file for uploading to ftp.gnu.org. That site is the natural upstream repository for the bulk of GNU Project packages, and the ".sig" files on that site should be the canonical signatures for those packages. That would allow one master signature file for a package--the binary ".sig" file that I and other GNU Project maintainers upload to GNU's FTP site along with a package. Now that lintian is throwing an error if a ".orig.tar.gz.asc" file is missing, addressing this change is more important. I realize that packaging tools will also need to recognize and use a ".sig" file as an alternative to a ".asc" file. Multiple applications can create packages, so multiple bug reports might be necessary to make that change. In my case, I am using pdebuild. It did not recognize a ".sig" file that I created for a ".orig.tar.gz" file (I just tried after getting the lintian error). Running a command of the form "gpg --verify mypkg_orig.tar.gz.sig" sees that the signature is valid for the tarball. In the meantime, will anyone object to our using a lintian override for this? Thanks, Paul Hardy
Bug#549233: docbook-to-man: Does not accept (some) (unicode) characters
Helge, I looked at this bug report because I was looking into other things related to DocBook and man pages. I think this is not a bug. If you look at the file you attached with "less", you will see characters such as "" and "". Those are the hexadecimal values of Latin1 characters, not parts of UTF-8 characters. Maybe you accidentally attached the wrong file; I don't know. That would explain why there are no complaints when you try to convert this as a Latin1 document though. I am attaching a version of your document re-encoded as UTF-8 for you to experiment with. I did not try to process it. I also changed the "doctype" word on the first line to "DOCTYPE"; I think it is always supposed to be upper-case even if some tools don't complain. Because this is a DocBook file, you could try giving the filename the suffix ".xml" and insert this as a first line in the file to declare its encoding as UTF-8: You might also need to modify the system identifier in the DOCTYPE line. In summary, I think the problem is that the document you attached is not a valid UTF-8 document. There might be other reasons why it is also not a valid SGML document. The "emacs" editor will recognize SGML documents as such if the filename ends in ".sgml". I do not know how well it validates general SGML files though. If you end the filename in ".xml", you can enable Nxml mode in emacs. See https://www.emacswiki.org/emacs/UsingNxmlModeWithDocBook for more information. Note that some older emacs instructions might say you need to download the Nxml package and install it for emacs, but recent versions of emacs include it. I do not know what other validation tools are available for general SGML files on Debian, apart from xsltproc. I am not the maintainer of this package, and DocBook 4.1 is very, very old at this point, but I am posting this in case it helps you resolve this bug. Hopefully, this is also enough information for you to decide to close the bug. Good luck, Paul Hardy FIXME"> Niedermeyer"> FIXME 2009"> 1"> chias...@bsi.bund.de"> CHIASMUS"> Debian"> GNU"> GPL"> "> ]> FIXME 2009 Demo for docbook-to-man problems -hilfe -beispiel BESCHREIBUNG is some programme Für Hinweise zur Sicherheit siehe "HINWEISE", für erste Schritte siehe "EINFÜHRUNG" und für weiter Anwendungsbeispiele "BEISPIELE". Testing ß. OPTIONEN Zwischen einer Option und dem zugehörigen Parameter können, müssen aber keine Leerzeichen stehen. Die Optionen können in beliebiger Reihenfolge angegeben werden. Wird eine Option mehrfach angegeben, so wird nur das letzte Auftreten der Option (bzw. der zugehörige Parameter) ausgewertet. Wildcards werden von chiasmus nicht unterstützt. -hilfe Gibt eine kurze Hilfe aus. -beispiel Gibt Beispiele zur Verwendung von Chiasmus aus. -m something some text Beispiele: a. This is something b. Something else c. Even more so d. A fourth item e. A fifth item -q something Does somthing more Beispiele: a. Should be a) (restarted) b. Should be b) % demo something ... Hinweis: Die Option -q braucht nicht mit angegeben zu werden. Das Kommando % demo something else leistet dasselbe wie das Kommando in Beispiel a. -z Options FIXME some text Beispiele: a. Should be again a) b. Should be again b)
Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts
I am adding the maintainer of the New Maintainer's Guide and the Guide for Debian Maintainers, Osamu Aoki, to this discussion. I would like to reassign this wishlist bug to one of those packages if Osamu agrees. On Sun, Jul 16, 2017 at 6:59 PM, Paul Hardy <unifoun...@gmail.com> wrote: > Sean, > > On Sun, Jul 16, 2017 at 5:42 PM, Sean Whitton <spwhit...@spwhitton.name> > wrote: >> Hello Paul, >> >> On Sun, Jul 16, 2017 at 04:28:03PM -0700, Paul Hardy wrote: >>> My intention was to point someone new to packaging fonts in Debian in >>> the direction of an easy path, rather than leaving it up to that >>> person to find things out the hard way--or worse yet, doing things the >>> hard way. >> >> Right. It would be good to have that somewhere ... >> >>> How about a footnote pointing to >>> https://wiki.debian.org/Fonts/PackagingPolicy? That document is not >>> formal policy, but it would make life easier for someone if they are >>> new to packaging fonts. >>> >>> Alternatively, do you think this bug report should get reassigned to >>> the New Maintainer's Guide and be addressed as a request there? The >>> scope of that guide is mainly to walk someone through creating a >>> simple binary package. >> >> ... and the new maintainer's guide seems like a decent place. >> >> How about adding a section to that guide listing links to packaging >> guides for specific types of packages, such as fonts? > > I can certainly do that if the maintainer of that package would like > to add such a section. I have filed a bug report with a set of > proposed patches for maint-guide, and would wait for that to get > processed first (with my patches accepted or rejected). Osamu: Do you think that mentioning font packaging in the Guide for Debian Maintainers or the New Maintainer's Guide is appropriate? If so, I will reassign this bug to the package you prefer. I think just a pointer to https://wiki.debian.org/Fonts/PackagingPolicy with a brief explanation will be enough, with the expectation that the Fonts Wiki page will always have the most current information. If you do not think that information about packaging fonts belongs in either guide, let me know and I will try to come up with some other idea. As of today, the New Maintainer's Guide is still required reading for New Maintainers, but the Guide for Debian Maintainers is not required reading. I will assume that is going to change in the future with Osamu's focus on the latter document going forward if font packaging information is added there. Otherwise, someone wanting to package fonts for Debian for the first time could still wind up having to hunt for and hopefully be lucky enough to find the Fonts Wiki page to learn how. Thank you, Paul Hardy
Bug#868497: debian-policy: Signed .dsc Files
On Sun, Jul 16, 2017 at 5:46 PM, Sean Whitton <spwhit...@spwhitton.name> wrote: > Hello Paul, > > On Sun, Jul 16, 2017 at 04:36:55PM -0700, Paul Hardy wrote: >> I was wondering if a maintainer signed a .dsc file in a package that >> was uploaded (and hence signed) by a sponsor, that the FTP server >> would reject the .dsc file for having an invalid signature. > > The sponsor would probably unpack and then rebuild the source package > for the upload. > > If they didn't, and directly signed the .dsc using debsign(1), it would > strip the sponsee's signature, and then sign both the .dsc and the > .changes. > > So I believe the problem case could not arise. Okay, if debsign will strip off any existing signature before applying the uploader's signature, then it sounds like the situation will not arise. That being the case, I will close this bug. Thank you, Paul
Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts
Sean, On Sun, Jul 16, 2017 at 5:42 PM, Sean Whitton <spwhit...@spwhitton.name> wrote: > Hello Paul, > > On Sun, Jul 16, 2017 at 04:28:03PM -0700, Paul Hardy wrote: >> My intention was to point someone new to packaging fonts in Debian in >> the direction of an easy path, rather than leaving it up to that >> person to find things out the hard way--or worse yet, doing things the >> hard way. > > Right. It would be good to have that somewhere ... > >> How about a footnote pointing to >> https://wiki.debian.org/Fonts/PackagingPolicy? That document is not >> formal policy, but it would make life easier for someone if they are >> new to packaging fonts. >> >> Alternatively, do you think this bug report should get reassigned to >> the New Maintainer's Guide and be addressed as a request there? The >> scope of that guide is mainly to walk someone through creating a >> simple binary package. > > ... and the new maintainer's guide seems like a decent place. > > How about adding a section to that guide listing links to packaging > guides for specific types of packages, such as fonts? I can certainly do that if the maintainer of that package would like to add such a section. I have filed a bug report with a set of proposed patches for maint-guide, and would wait for that to get processed first (with my patches accepted or rejected). Take care, Paul Hardy
Bug#868497: debian-policy: Signed .dsc Files
Russ, On Sun, Jul 16, 2017 at 10:56 AM, Russ Allbery <r...@debian.org> wrote: > Paul Hardy <unifoun...@gmail.com> writes: > >> ...Debian Policy Manual, Section 5.4, "Debian source control files - .dsc", >> states in the first sentence: > >> "This file consists of a single paragraph, possibly surrounded by a PGP >> signature." > >> This does not state whether someone who is creating a package to be >> uploaded by a sponsor can clearsign their own .dsc file, or if only the >> sponsor is able to do that without causing upload problems. > >> What is permissible? Can you clarify that in a future update to this >> section? > > (I'm pretty sure the actual answer to this question is that nothing > cares.)... I was wondering if a maintainer signed a .dsc file in a package that was uploaded (and hence signed) by a sponsor, that the FTP server would reject the .dsc file for having an invalid signature. Could the wording be changed to "...possibly surrounded by the maintainer's PGP signature"? The term "maintainer" is implicitly defined in the Policy Manual through repeated mention. Of course, out of context of this request someone might think "of course the maintainer would sign the .dsc file--who else would do that?" Thanks, Paul Hardy
Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts
Control: severity 868496 wishlist On Sun, Jul 16, 2017 at 1:01 PM, Sean Whitton <spwhit...@spwhitton.name> wrote: > Hello Paul, > > On Sun, Jul 16, 2017 at 02:56:24AM -0700, Paul Hardy wrote: >> Then would you consider it acceptable to make some mention in a >> footnote to the effect that with the latest "dh" build tools, it isn't >> necessary to have postinst and postrm scripts in the debian directory >> for this purpose? Because otherwise, someone who did not already know >> about this could misunderstand the implications of this requirement >> and create redundant postinst and postrm scripts. > > The problem is that if we think there should be footnotes explaining > that there is a dh_* tool that takes care of the requirement, we would > then need new footnotes to almost every section of Policy. That would > be a bad idea. Yes, I could see that spiraling out of control. My intention was to point someone new to packaging fonts in Debian in the direction of an easy path, rather than leaving it up to that person to find things out the hard way--or worse yet, doing things the hard way. How about a footnote pointing to https://wiki.debian.org/Fonts/PackagingPolicy? That document is not formal policy, but it would make life easier for someone if they are new to packaging fonts. Alternatively, do you think this bug report should get reassigned to the New Maintainer's Guide and be addressed as a request there? The scope of that guide is mainly to walk someone through creating a simple binary package. I have downgraded this bug to "wishlist" because it is not an actual issue with Debian Policy. Thanks, Paul Hardy
Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts
Andrey, On Sun, Jul 16, 2017 at 12:21 AM, Andrey Rahmatullin <w...@debian.org> wrote: > On Sat, Jul 15, 2017 at 09:57:32PM -0700, Paul Hardy wrote: >> "Font packages must invoke update-fonts-dir on each directory into >> which they install fonts. This invocation must occur in both the >> postinst (for all arguments) and postrm (for all arguments except >> upgrade) scripts." >> >> Strictly speaking this is correct, but it could be taken to mean that >> a font packager must have postinst and postrm scripts in their >> package's debian directory. That is no longer necessary. I suggest >> appending the following to the above paragraph: >> >> "Note: if your build scripts invoke dh_installxfonts, this is handled >> automatically and it is not necessary to create postinst or postrm >> files in your debian directory for this purpose. See >> dh_installxfonts(1)." > No, the policy doesn't talk about dh_* and other helpers (except in > footnotes). Then would you consider it acceptable to make some mention in a footnote to the effect that with the latest "dh" build tools, it isn't necessary to have postinst and postrm scripts in the debian directory for this purpose? Because otherwise, someone who did not already know about this could misunderstand the implications of this requirement and create redundant postinst and postrm scripts. Thanks, Paul Hardy
Bug#868497: debian-policy: Signed .dsc Files
Package: debian-policy Version: 4.0.0.4 Severity: wishlist -- Debian Policy Manual, Section 5.4, "Debian source control files - .dsc", states in the first sentence: "This file consists of a single paragraph, possibly surrounded by a PGP signature." This does not state whether someone who is creating a package to be uploaded by a sponsor can clearsign their own .dsc file, or if only the sponsor is able to do that without causing upload problems. What is permissible? Can you clarify that in a future update to this section? Thank you, Paul Hardy
Bug#868496: debian-policy: Please Clarify Need for update-fonts-dir in postinst and postrm Scripts
Package: debian-policy
Version: 4.0.0.4
Severity: minor
--
The Debian Policy Manual, Section 11.8.5, "Packages providing fonts",
states in item 12:
"Font packages must invoke update-fonts-dir on each directory into
which they install fonts. This invocation must occur in both the
postinst (for all arguments) and postrm (for all arguments except
upgrade) scripts."
Strictly speaking this is correct, but it could be taken to mean that
a font packager must have postinst and postrm scripts in their
package's debian directory. That is no longer necessary. I suggest
appending the following to the above paragraph:
"Note: if your build scripts invoke dh_installxfonts, this is handled
automatically and it is not necessary to create postinst or postrm
files in your debian directory for this purpose. See
dh_installxfonts(1)."
The man page for dh_installxfonts(1) states:
"Your package should depend on xfonts-utils so that the update-fonts-*
commands are available. (This program adds that dependency to
${misc:Depends}.)
"This program automatically generates the postinst and postrm commands
needed to register X fonts. These commands are inserted into the
maintainer scripts by dh_installdeb. See dh_installdeb(1) for an
explanation of how this works."
See also the Debian Fonts Packaging Policy page at
https://wiki.debian.org/Fonts/PackagingPolicy.
The new "dh $@" rules format invokes dh_installxfonts on a font
package at the appropriate time.
Thank you,
Paul Hardy
Bug#473227: less: Prints UTF-8 Byte order mark
Control: tags 473227 + fixed-upstream The "less" upstream maintainer, Mark Nudelman, has just emailed me saying that he believes he has fixed this bug in less version 504, just released. See http://greenwoodsoftware.com/less/less-504.tar.gz Russ: if this upstream release is uploaded to Debian, would you be amenable to starting Debian UTF-8 documents with the UTF-8 signature? Then they would appear correctly in web browsers no matter what Content or Meta tags say. This same issue applies to other Debian documents of course (such as the txt versions of maint-guide). Thanks, Paul Hardy
Bug#833322: maint-guide: don't suggest low urgency for uploads of new packages
Also, FWIW, "low" urgency packages are now only held in unstable for 5 days before migrating, not 10 days. I don't know whether this is temporary or permanent. If permanent, there isn't much of a reason for "low" urgency anymore. I recently prepared a package and set the urgency to "low" because I made changes in a number of source code files all at once to support a data file structure change. I intended the package to sit in "unstable" for 10 days to give time for any catastrophic error to surface, which is how I discovered this. I just mentioned this as an aside at the end of bug report #868281 but figured I should also add that info to this bug report. Thanks, Paul Hardy
Bug#868277: maint-guide: Typos, Typography, and Grammar Patches
Because there are so many patches in the original attachment for this bug report, I am attaching a GPG signature of the gzipped patch file in this message for verification. Thanks, Paul Hardy doc-patches.txt.gz.sig Description: PGP signature
Bug#843207: ITP: man2texi -- man page to texinfo file converter
This is a status update. With the Stretch release, work is picking up on this ITP again. I have send Nelson Beebe some files he requested for testing with the latest version of texinfo. I will be continuing to work with him on getting a new and improved man2texi into Debian that carries his approval. Thanks, Paul Hardy
Bug#843207: ITP: man2texi -- man page to texinfo file converter
This is a status update. With Debian 9 ("Stretch") released, I am
picking up work on this ITP again.
I have sent Nelson Beebe some files he requested for testing with the
latest version of texinfo. I will be continuing to work with him on
getting a version of man2texi into Debian that carries his approval.
Thanks,
Paul Hardy
Bug#868281: maint-guide: Priority "extra" is gone
Package: maint-guide Version: 1.2.39 Severity: normal -- The maint-guide package mentions (and recommends) using priority "extra" in several places, with examples. The FTP Masters have removed this priority. If a package is loaded with priority "extra" now, that will generate a lintian warning. Please consider changing priority "extra" to priority "optional" wherever it appears in the maint-guide package. Also, the maint-guide package mentions using urgency "low". Be aware that "low" urgency only seems to leave packages in unstable now for 5 days, not 10 days. I don't know if that is a temporary change or is permanent. If a permanent change, you might also consider changing the text to use "normal" urgency. Thanks, Paul Hardy
Bug#868279: maint-guide: deprecated "--force-yes" apt-get option in pbuilder hooks script
Package: maint-guide Version: 1.2.39 Severity: wishlist -- In Chapter 6 of the maint-guide package, the B90lintian hooks script for pbuilder contains the line apt-get -y --force-yes install "$@" The "--force-yes" option is deprecated; apt-get recommends replacing it with one of the "--allow-*" options. However, the apt-get man page warns that all of those options are "dangerous". The example B90lintian script in /usr/share/doc/pbuilder/examples/B90lintian simply omits the "--force-yes" option and does not replace it with an "--allow-*' option. Please consider just removing the "--force-yes" option in the B90lintian example in maint-guide Chapter 6. Thanks, Paul Hardy
Bug#868278: maint-guide: Please Recommend Debhelper 10
Package: maint-guide Version: 1.2.39 Severity: wishlist -- Debhelper 10 is now in stable. Please consider updating maint-guide to recommend its use in debian/control and debian/compat instead of using Debhelper 9. See debhelper(7) and https://nthykier.wordpress.com/2016/09/11/debhelper-10-is-now-available/. Thanks, Paul Hardy
Bug#868277: maint-guide: Typos, Typography, and Grammar Patches
Package: maint-guide
Version: 1.2.39
Severity: normal
Tags: patch
--
I have read the Maintainer's Guide, and while reading it also
proofread it. The patch file addresses typos and some grammar (such
as "which" versus "that"). I also made some typography-related
changes:
"..." became a horizontal ellipsis ("" aka Unicode code point U+2026)
"-" became, according to context, an en-dash ("" aka U+2013),
an em-dash ("" aka U+2014), or remained a hyphen.
The HTML5 entities for the above symbols are not defined in the
maint-guide files; for reference, they are:
U+2026:
U+2013:
U+2014:
See, for example, "https://www.w3schools.com/charsets/ref_utf_punctuation.asp;.
If not a huge effort, it would be good to add XML entities defining
those code points to match their HTML5 entity definitions, since
maint-guide uses them frequently.
On the various types of dashes, a good reference is _The TeXbook_ by
Donald Knuth. On p. 4 of my copy, he says:
"Book printing differs significantly from ordinary typing with respect
to dashes, hyphens, and minus signs. In good math books, these
symbols are all different; in fact there usually are at least four
different symbols:
a hyphen (-);
an en-dash (–);
an em-dash (—);
a minus sign (−).
"Hyphens are used for compound words like 'daughter-in-law' and
'X-rated'. En-dashes are used for number ranges like 'pages 13–34',
and also in contexts like 'exercise 1.26–52'. Em-dashses are used for
punctuation in sentences—they are what we often call simply dashes.
And minus signs are used in formulas."
If more convenient, I could send an attachment of the entire gzipped
"doc-new" directory. There are over 100 changes, and all the chapters
are modified. I have not changed anything substantive, but will file
a couple of non-typo-related bugs for other aspects of maint-guide.
Thanks,
Paul Hardy
doc-patches.txt.gz
Description: GNU Zip compressed data
Bug#867220: unifont-bin: "Priority: extra" should be "Priority: optional"
Package: unifont-bin Version: 1:10.0.01-1 Severity: normal -- There is no more "extra" priority in Debian. The unifont-bin "Priority" field should be updated to "optional" to match the package override. This will be fixed in the next Unifont upload. Thanks, Paul Hardy
Bug#866192: Broken Link in Policy HTML Page
Sean, On Sat, Jul 1, 2017 at 7:55 AM, Sean Whitton <spwhit...@spwhitton.name> wrote: > Hello Paul, Russ, > > On Tue, Jun 27, 2017 at 10:16:16PM -0700, Russ Allbery wrote: >> We should probably open a bug for this since it's not entirely obvious >> what to do here. I can think of three options: >> >> * Ask debian-www to publish the HTML version of that file as well. >> * Change the link to point to the wiki version of the file. >> * Convert the process doc to DocBook so that we can make it an appendix. >> >> I'm kind of leaning towards the last, honestly. > > Agreed. It should be easy enough to convert back and forth with pandoc, > and it's much better to have this in our git repo than on the wiki. An > appendix is also significantly easier for people to find. This is now filed as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866192. I am CCing this message there. Thanks, Paul Hardy
Bug#866690: fontforge: missing man pages for fontforge, sfddiff
Package: fontforge Version: 1:20161005~dfsg-4 Severity: normal Tags: patch -- The current fontforge package on Debian is missing man pages for fontforge and sfddiff. I discovered this while setting up stretch on my computer. I asked upstream if they would be interested in man pages, and Dave Crossland replied that he would. So I created new man pages and sent them to Dave for vetting. I wrote the attached man pages by reconstructing an old version of each that appears on linux.die.net, and then updating them based on "help" output from the program versions installed in Debian stable. Thanks, Paul Hardy fontforge.1 Description: Binary data sfddiff.1 Description: Binary data
Bug#696254: qa.debian.org: PTS has outdated current policy version
There is a bug in the code for checking a major standards version increment. For example, the page for Unifont (https://packages.qa.debian.org/u/unifont.html) contains this item in the "Problem" section: "The package is severly out of date with respect to the Debian Policy. Latest version is 3.9.8 and your package only follows 4.0.0..." Note also the misspelling of "severely" as "severly". The new tracker spells this correctly. Paul Hardy
Bug#866192: debian-policy: Broken Link in Policy HTML Page
Package: debian-policy Version: 4.0.0.4 Severity: normal -- Dear debian-policy Maintainers: -- Forwarded message -- From: Russ Allbery <r...@debian.org> Date: Tue, Jun 27, 2017 at 10:16 PM Subject: Re: Broken Link in Policy HTML Page To: Paul Hardy <unifoun...@gmail.com> Cc: debian-pol...@lists.debian.org Paul Hardy <unifoun...@gmail.com> writes: > The web page https://www.debian.org/doc/debian-policy/ch-scope.html > contains a link labeled "Policy" in Section 1.3. It points to > https://www.debian.org/doc/debian-policy/Process.md, which does not > exist. I figure this is a quick fix not needing a full bug report. We should probably open a bug for this since it's not entirely obvious what to do here. I can think of three options: * Ask debian-www to publish the HTML version of that file as well. * Change the link to point to the wiki version of the file. * Convert the process doc to DocBook so that we can make it an appendix. I'm kind of leaning towards the last, honestly. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature
Given all the discussion that has taken place, what do you think of: 1) Serving debian-policy pages on Debian servers as UTF-8 documents, as an interim measure. 2) Given that this is only a solution for web servers under Debian's control, given that using the UTF-8 signature is now accepted Unicode practice and will force correct interpretation in HTML5-compliant browsers regardless of any conflicting HTTP headers or META charset tags, introducing the UTF-8 signature (\357\273\277) at the start of UTF-8 documents if an upstream release of package "less" no longer displays this sequence. LibreOffice Writer on Stretch does insert the UTF-8 signature at the beginning of a ".txt" file saved in UTF-8 format, as described in "less" bug 473227 with respect to OpenOffice. Thanks, Paul Hardy
Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature
Paul,
On Sun, Jun 25, 2017 at 8:24 PM, Paul Wise <p...@debian.org> wrote:
> On Sun, 2017-06-25 at 16:07 -0700, Paul Hardy wrote:
>
>> Earlier today, I sent the GNU less maintainer a two-line patch to the
>> "charset.c" file after my original email to him.
>
> I'm no expert on the less source code, but it seems to me that it will
> also hide U+FEFF characters after the first one.
You are correct.
> I would suggest
> updating it so that <U+FEFF> is only hidden when it is the first UTF-8
> character in the file.
Well, U+FEFF has a dual personality. It began its life as "ZERO WIDTH
NO-BREAK SPACE (ZWNBSP)". Then that use became deprecated; new
documents were supposed to use U+2060 ("WORD JOINER") instead. Of
course, there might still be legacy documents around, and less might
have to display them.
The alias for U+FEFF is "BYTE ORDER MARK (BOM)", and U+FEFF can go by
either of its names.
If used as a BOM, then U+FEFF is supposed to appear at the beginning
of a document according to The Unicode Standard, and discarding all
instances of U+FEFF does not accommodate that.
But the proper handling of U+FEFF as ZWNBSP is to print zero width,
and not cause a break between the surrounding characters. You get
that alternate effect by not printing the character, which is what the
patch does.
However, in the HTML5 link I posted earlier, it mentions that a
compliant HTML5 web browser must detect the BOM anywhere within an
HTML document and if present, treat the web page as having UTF-8
encoding (or UTF-16, depending on the BOM format encountered). They
mention the reason for this is to allow web servers to claim that they
are serving one type of content in a generic fashion, but individual
Unicode documents that are embedded in the HTML response still should
correctly display. The presence of the BOM anywhere in the web page
is supposed to override the HTTP header charset and any META charset
tags, if present. The latter requires interpreting U+FEFF anywhere in
the web page as a BOM.
This is a quote from p. 866 of the Unicode Standard 10.0.0 that goes
into some of the context-sensitive nature of U+FEFF (but note that
nobody is supposed to be using U+FEFF as a ZWNBSP, as of over a decade
ago):
"Where the byte order is explicitly specified, such as in UTF-16BE or
UTF-16LE, then all U+FEFF characters—even at the very beginning of the
text—are to be interpreted as zero width no-break spaces. Similarly,
where Unicode text has known byte order, initial U+FEFF characters are
not required, but for backward compatibility are to be interpreted as
zero width no-break spaces. For example, for strings in an API, the
memory architecture of the processor provides the explicit byte order.
For databases and similar structures, it is much more efficient and
robust to use a uniform byte order for the same field (if not the
entire database), thereby avoiding use of the byte order mark.
"Systems that use the byte order mark must recognize when an initial
U+FEFF signals the byte order. In those cases, it is not part of the
textual content and should be removed before processing, because
otherwise it may be mistaken for a legitimate zero width no-break
space. To represent an initial U+FEFF zero width no-break space in a
UTF-16 file, use U+FEFF twice in a row. The first one is a byte order
mark; the second one is the initial zero width no-break space. See
Table 23-6 for a summary of encoding scheme signatures."
Yet the only "processing" that less should be doing is outputting one
line at a time. It does not figure out line breaks dynamically the
way a WISYWIG word processor program would, for example. If it did,
then this dual-personality of U+FEFF would probably require
introducing an additional state variable into less.
So I think recognizing and discarding all occurrences of the BOM in
less produces the desired effect in all cases.
Paul
