Bug#925200: missing warning for wrong path

[Osamu Aoki]

control: retitle -1 check doc-base-file-references-wrong-path
control: tags -1 + patch

Excuse me, lintian warning was correct.

But after checking this bug of mine, I came up with a possible
improvement for the lintian check.  I made a proof-of-concept patch
here.

Package: lintian
Version: 2.11.0
Severity: normal

Requested action for /usr/share/lintian/checks/menus.pm:


   * add sanity check for the file path to be usr/share/doc/*
 or /usr/share/info/*.
 --> /usr/share/lintian/checks/menus.pm before line 353
 add file path matching rule and produce error message as
 needed.

Attached a proof of concept patch:

Note:
I didn't run perltidy since that changed many other parts.

I still didn't figure out how the test suite within lintian works.
This code is tested by installing it to the target pat manually ;-)

Osamu

PS: I at least see that libreoffice-help-en-us should fail this new
test.  It shouldn't list /usr/share/libreoffice/help/media/* which is
outside of /usr/share/doc/*.  Instead, it should create symlink using
dh_link:
  /usr/share/doc//help -> /usr/share/libreoffice/help
Then use this new path for doc-base.

PS sixerjman: I think your concern is addressed with lintian now.
>From 30479d72937d84fbd501f2f61d40cb1169cb35bd Mon Sep 17 00:00:00 2001
From: Osamu Aoki 
Date: Thu, 21 Mar 2019 20:43:22 +0900
Subject: [PATCH 1/1] Add check for doc-base-file-references-wrong-path

This test make sure that the files referenced in an Index or Files field
always uses correct path as requested by doc-base 2.3.2.2.

Signed-off-by: Osamu Aoki 
---
 checks/menus.desc | 8 
 checks/menus.pm   | 5 +
 2 files changed, 13 insertions(+)

diff --git a/checks/menus.desc b/checks/menus.desc
index af26ee9..06c1e8a 100644
--- a/checks/menus.desc
+++ b/checks/menus.desc
@@ -144,6 +144,14 @@ Info: The Index field in a doc-base file should reference the single index
  should be listed in the Files field.
 Ref: doc-base 2.3.2.2
 
+Tag: doc-base-file-references-wrong-path
+Severity: important
+Certainty: certain
+Info: One of the files referenced in an Index or Files field in this
+ doc-base control file lists a wrong file path which doesn't start with
+ /usr/share/doc/ nor with /usr/share/info/.
+Ref: doc-base 2.3.2.2
+
 Tag: doc-base-file-references-missing-file
 Severity: important
 Certainty: certain
diff --git a/checks/menus.pm b/checks/menus.pm
index f66d825..521ab5d 100644
--- a/checks/menus.pm
+++ b/checks/menus.pm
@@ -350,6 +350,11 @@ sub check_doc_base_field {
 if ($field eq 'index' && @files > 1) {
 tag 'doc-base-index-references-multiple-files', "$dbfile:$line";
 }
+for my $file (@files) {
+next if $file =~ m %^/usr/share/doc/%;
+next if $file =~ m %^/usr/share/info/%;
+tag 'doc-base-file-references-wrong-path', "$dbfile:$line", $file;
+	}
 for my $file (@files) {
 next if $file eq '';
 my $realfile = delink($file, $all_links);
-- 
2.20.1

Bug#925200: doc-base-file-references-missing-file: false positive and missing warning when symlinks are involved

[Osamu Aoki]

Package: lintian
Version: 2.11.0
Severity: normal

Requested action for /usr/share/lintian/checks/menus.pm:


   * add feature to "delink" to follow relative symlink
 --> /usr/share/lintian/checks/menus.pm around line 566-592
 relative symlink needs to be converted to absolute one before
 doing the path matching
   * add sanity check for the file path to be usr/share/doc/*
 or /usr/share/info/*.
 --> /usr/share/lintian/checks/menus.pm before line 353
 add file path matching rule and produce error message as
 needed.

(I am not a good Perl user ... so no patch for now.)

Problem:


Currently, lintian warns like:
E: debian-reference-en: doc-base-file-references-missing-file 
debian-reference-en:9 
/usr/share/doc/debian-reference/docs/debian-reference.en.txt.gz
E: debian-reference-en: doc-base-file-references-missing-file 
debian-reference-en:12 /usr/share/doc/debian-reference/docs/index.en.html
E: debian-reference-en: doc-base-file-references-missing-file 
debian-reference-en:13 /usr/share/doc/debian-reference/docs/*.en.html
These are false positive error messages.

libreoffice-help-en-us and similar packages also suffer this bug and set
up overrides for now.  So this is not-so-isolated case and this lintian
error may lure people in wrong direction as I explain below.  So it's
worth fixing.

Error analysis:
===

For the above debian-refgerence-en case, "docs" is a relative symlink
generated by dh_link which generates symlinks that comply with Debian
policy - absolute when policy says they should be absolute, and relative
links with as short a path as possible.  It will also create any
subdirectories it needs to put the symlinks in.

Actual files are located in places outside of /usr/share/doc/ such as
/usr/share/debian-reference/index.en.html This is in accordance with
Policy 12.3. Additional documentation:
| Packages must not require the existence of any files in /usr/share/doc/
| in order to function. [6] Any files that are used or read by programs
| but are also useful as stand alone documentation should be installed
| elsewhere, such as under /usr/share/package/, and then included via
| symbolic links in /usr/share/doc/package.

So this lintian error is false positive.

As I see the source of lintian, /usr/share/lintian/checks/menus.pm has
code to normalize symlinks as "delink".

Apparently, this only normalize the absolute path symlink case.

So updating this code to handle the relative path symlink is needed.

In addition to this, this bug may have lured people to wrong packaging
practices and that's need to be addressed.  People could avoid this
lintian error by listing actual file paths without symlink in it such as
/usr/share/debian-reference/index.en.html in the doc-base configuration
file (debian/.doc-base).  This is very bad move.  Policy "9.10.
Registering Documents using doc-base" instructs us "Please refer to the
documentation that comes with the doc-base package for information and
details." and in "2.3.2.2. Format sections" of the documentation that
comes with the doc-base package clearly prohibits such move.

| Except for the Info format the files referred in both Index and Files
| fields should be placed somewhere under the /usr/share/doc hierarchy. If
| for some reason it's not possible, then the registering package should
| provide a symbolic link pointing from the above hierarchy to the real
| files and register its documentation through the link, allowing
| doc-base, dhelp, or dwww packages to actually handle the documentation.
| Of course, files in the Info format should be located in the
| /usr/share/info directory. 

So lintian should check if the listed file path starts as /usr/share/doc
or /usr/share/info before checking the existence of target file.

Note for normalize relative symlink:


Line 566 needs to be updated as:
# In the loop below we split $file into two parts on each '/' until
# there's no remaining slashes.  We try substituting the first part with
# corresponding symlink and if it succeeds, we start the procedure from
# beginning.
#
# Example1:
#Let $all_links{"/a/b"} == "/d", and $file == "/a/b/c"
#Then 0) $p1 == "", $p2 == "/a/b/c"
# 1) $p1 == "/a",   $p2 == "/b/c"
# 2) $p1 == "/a/b", $p2 == "/c"  ; substitute "/d" for "/a/b"
# 3) $p1 == "", $p2 == "/d/c"
# 4) $p1 == "/d",   $p2 == "/c"
# 5) $p1 == "/d/c", $p2 == ""
#
# Example2: (this needs to be added)
#Let $all_links{"/a/b"} == "../../d", and $file == "/a/b/c"
#Then 0) $p1 == "", $p2 == "/a/b/c"
# 1) $p1 == "/a",   $p2 == "/b/c"
# 2) $p1 == "/a/b", $p2 == "/c"  ; add "../../d" to "/a/b"
# 3) $p1 == "/a/b/../../d", $p2 == "/c"; normalize
# 4) $p1 == "/d",   $p2 == "/c"
   

Bug#505857: tagging 505857

[Osamu Aoki]

control: tags 505857 - pending

thanks

Osamu

Bug#505857: lintian: false positive debian-watch-file-should-mangle-version

[Osamu Aoki]

Hi,

Bug:
 https://bugs.debian.org/505857
 https://bugs.debian.org/884880 (cloned bug of above)

I just updated manpage of uscan to reduce stress of our fellow DDs for
Bug #884880.

I agree with
> 3.- Long term solution:
> Turn some portions of uscan into a perl module[1] and use it to extract the
> dversionmangle regex.

I agree uscan deserves more code refactoring and it should expose its
internal utilities to other codes.  Unfortunately, my skill and time is
not up for the task.

So I simply addressed Chris's concern https://bugs.debian.org/884880#57
by updating the manpage to point people to the pertinent information.  I
hope the recent checkin is good enough.
 57ea0c53 ("uscan: clarify the importance of version=4", 2018-01-12)

But what is this "[1]This is on my ToDo list for DEHS2 anyway." in bug
report? Raphael, are you still working on something?

Regards,

Osamu

Re: debian/upstream/signing-key.asc in policy 4.1.0

[Osamu Aoki]

Hi,

On Sun, Aug 27, 2017 at 08:51:49PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 23 Aug 2017, Russ Allbery wrote:
> > Note that this Policy language is carefully written to make it perfectly
> > fine for uscan to support all the things it currently supports, since it
> > only talks about what Policy recommends the maintainer does.  So don't
> > feel any obligation to change what uscan is doing on Policy's account
> > here.
> 
> Actually, the text in 4.1.0.0 might be doing too much.  It reads:
> 
> "If the upstream maintainer of the software provides OpenPGP signatures
> for new releases, including the information required for "uscan" to
> verify signatures for new upstream releases is also recommended. To do
> this, use the "pgpsigurlmangle" option in "debian/watch" to specify
> the location of the upstream signature, and include the key or keys
> used to sign upstream releases in the Debian source package as
> "debian/upstream/signing-key.asc".
> 
> IMO, it should either not be mandating uscan internals, or it should be

In principle, you comment is a very reasonable one.

> very clear about the exact subset of stuff we can use in debian/watch
> (version, etc).  For example, I'd rather use opt="..., pgpmode=auto,..."
> instead of explicitly hardcoding a "pgpsigurlmangle".

The new pgpmode=auto and pgpmode=previous have bugs and fail to function
smoothly ---  #873289 #852537  Excuse me for these bugs.  The fixes have
been committed to git.  I am hoping the next upload of devscripts (and
its backport) will fix them.  So "pgpsigurlmangle" is the only good way
at this moment.
 
> IMHO, just drop everything from "To do this..." to the end of that
> paragraph entirely.  HOW one gets "uscan" to fetch and check upstream
> signatures is a job for the uscan(1) manpage.  Alternatively, just
> mention "debian/watch", and to refer to the uscan documentation in
> package "devscripts".

Once pgpmode=auto becomes noise free, this should be the preferred
choice.  It will be nice to address #833012, too, using s/\?/.asc?/ etc.
to make it really default one.

So for now, the policy text is better for me.

> OTOH, if we really need to mandate a specific level of debian/watch
> support, the current text in policy needs work: it doesn't even tell me
> whether I can use version=3 (supported in oldstable), or version=4
> (supported in oldstable-backports and stable), for example...

The uscan version=3/version=4 difference is not much about enhanced
mangling rules.  It's about how uupdate is invoked and how uupdate
creates the updated source tree.  version=4 uses dpkg-source as back-end
and capable of generating multi-upstream tarball.

If you use new uscan, even with a watch file marked as version=3, it has
access to the enhanced mangling rules.

Osamu

Re: debian/upstream/signing-key.asc in policy 4.1.0

[Osamu Aoki]

Oops.

On Sun, Aug 27, 2017 at 12:55:26AM +0900, Osamu Aoki wrote:
> Hi,
> 
> On Wed, Aug 23, 2017 at 09:27:25AM -0700, Russ Allbery wrote:
> > Osamu Aoki <os...@debian.org> writes:
> > > The updated uscan will support debian/upstream/signing-key.asc only and
> > > internally convert it /signing-key.gpg.  I will make uscan to
> > > convert other formats to this policy compliant *.asc.  Also make noise
> > > to the maintainer to push them to policy 4.1.0
> > 
> > Note that this Policy language is carefully written to make it perfectly
> > fine for uscan to support all the things it currently supports, since it
> > only talks about what Policy recommends the maintainer does.  So don't
> > feel any obligation to change what uscan is doing on Policy's account
> > here.
> 
> Maybe I should have been a bit careful with my words:
> 
> The updated uscan will support debian/upstream/signing-key.asc only as
> the recommended keyring.  It will accept other historic keyrings but
> also internally converts them to /signing-key.gpg to guide

Of course:
  /signing-key.asc

> people to the new recommended format with some reminder noise.

Now committed to git.

Osamu

Re: debian/upstream/signing-key.asc in policy 4.1.0

[Osamu Aoki]

Hi,

On Wed, Aug 23, 2017 at 09:27:25AM -0700, Russ Allbery wrote:
> Osamu Aoki <os...@debian.org> writes:
> > The updated uscan will support debian/upstream/signing-key.asc only and
> > internally convert it /signing-key.gpg.  I will make uscan to
> > convert other formats to this policy compliant *.asc.  Also make noise
> > to the maintainer to push them to policy 4.1.0
> 
> Note that this Policy language is carefully written to make it perfectly
> fine for uscan to support all the things it currently supports, since it
> only talks about what Policy recommends the maintainer does.  So don't
> feel any obligation to change what uscan is doing on Policy's account
> here.

Maybe I should have been a bit careful with my words:

The updated uscan will support debian/upstream/signing-key.asc only as
the recommended keyring.  It will accept other historic keyrings but
also internally converts them to /signing-key.gpg to guide
people to the new recommended format with some reminder noise.

> That said, as discussed elsewhere, I'm a huge fan of there being only one
> way to do something like this, with some easy tools to convert other
> methods into that one method.  It reduces everyone's cognitive load in the
> future.

Yes.

Osamu

debian/upstream/signing-key.asc in policy 4.1.0

[Osamu Aoki]

Hi,

After all the discussion, Policy 4.1.0 goes as:

| 4.11. Optional upstream source location: debian/watch¶
| 
| This is an optional, recommended configuration file for the uscan
| utility which defines how to automatically scan ftp or http sites for
| newly available updates of the package. This is also used by some Debian
| QA tools to help with quality control and maintenance of the
| distribution as a whole.
| 
| If the upstream maintainer of the software provides OpenPGP signatures
| for new releases, including the information required for uscan to verify
| signatures for new upstream releases is also recommended. To do this,
| use the pgpsigurlmangle option in debian/watch to specify the location
| of the upstream signature, and include the key or keys used to sign
| upstream releases in the Debian source package as
| debian/upstream/signing-key.asc.
| 
| For more information about uscan and these options, including how to
| generate the file containing upstream signing keys, see uscan.

Please note few things which I failed to share:

The current uscan supports both 
 debian/upstream/signing-key.asc
 debian/upstream/signing-key.pgp

Now, if debian/upstream/signing-key.asc is used, uscan converts it to
/signing-key.gpg by gpg for use with gpgv to check
signature.  (I think the same goes with dpkg-source).  It looks extra
CPU power waste but not a big deal. I do this conversion since no
documentation mention keyring can be ascii armored for gpgv.

The updated uscan will support debian/upstream/signing-key.asc only and
internally convert it /signing-key.gpg.  I will make uscan to
convert other formats to this policy compliant *.asc.  Also make noise
to the maintainer to push them to policy 4.1.0

Regards,

Osamu

Bug#833585: lintian: Check presence of upstream signature if signing key available

[Osamu Aoki]

Hi, (This is RFH)

On Mon, Aug 21, 2017 at 09:43:13AM +0200, Kurt Roeckx wrote:
> On Mon, Aug 21, 2017 at 09:30:41AM +0200, Vincent Bernat wrote:
> >  ❦ 15 juillet 2017 23:06 +0100, Chris Lamb  :
...
> > Integration with uscan is not done either.

The stretch uscan has download and verification included.  The buster
uscan is aiming to do the proper renaming to match dpkg-source
expectation.

> There is a bug against uscan to do this, I understand that it's
> been committed just not uploaded yet.

Yes.  With test script run on the build time, I confirmed it is working.
(Cross my fingers)

The updated uscan should support typical upstream combinations:
 1) (foo-ver.tar.gz, foo-ver.tar.gz.{pgp,gpg,sgn,sign,asc})
-> (foo_ver.tar.orig.gz, foo_ver.orig.tar.gz.asc)
 2) (foo-ver.tar.gz, foo-ver.tar.{pgp,gpg,sgn,sign,asc})
-> (foo_ver.tar.orig.gz, foo_ver.orig.tar.asc)

I think the output of 1) is supported by the stretch dpkg-source but I
am not sure for the output of 2).

There is another way of signing package: non-detached signature
with gpg -s or gpg -sa.  Not so popular but there were wishlist bug for
it in BTS.  For such an upstream file, I wish to convert to 
-> (foo_ver.tar.orig.gz, foo_ver.orig.tar.gz.asc)
I know how to get the foo_ver.tar.orig.gz but the conversion of
signature to detached format seems non-intuitive task.  Your expert help
on gpg trick is most appreciated.

Regards,

Osamu

Re: Upstream Tarball Signature Files

[Osamu Aoki]

Hi,


On Fri, Aug 18, 2017 at 12:02:27PM +0200, Guillem Jover wrote:
..
> Adding support for more signature formats or filename variations is
> not hard, but it increases the amount of those extensions and perhaps
> the additional sanity checks we have to support and perform on them on
> multiple tools, etc. It would also require waiting at least once more
> release cycle until they can be used.

I just commited uscan/mk-origtargz support of these.

It will be nice dpkg can support both
 foo.tar.gz
 foo.tar.gz.asc
or 
 foo.tar.gz
 foo.tar.asc (signature on uncompressed)
combinations.

There are upstream releasing in these format.

More nasty one is releasing foo.tar.gz with "gpg -s" w/o -b as
foo.tar.gz.sig or "gpg -sa" as foo.tar.gz.asc.  I have no idea how to
extract signaturefile from non-detached signature.  That's remaining
task but a rare case.

Osamu

How to handle upstream tarbell signature

[Osamu Aoki]

Hi,

I was trying to update uscan and realized few problems which are not
addressed by the discussion here.  There are many things to consider.


On Fri, Aug 18, 2017 at 02:43:58PM +0200, Mattia Rizzolo wrote:
> On Fri, Aug 18, 2017 at 07:48:24AM -0400, Daniel Kahn Gillmor wrote:
> > I confess that i've been taking the boring/silly/cheating way out and if
> > upstream ships a detached binary signature as foo-1.2.3.tar.gz.sig, i've
> > just been manually renaming it to foo_1.2.3.orig.tar.gz.asc (without
> > even converting its contents to ASCII-armored form) and the rest of the
> > toolchain seems to just happily accept it -- it'd be even nicer if dpkg
> > and/or uscan was to normalize the contents to match the file extension.
> 
> That's because TTBOMK there is *nothing* atm actually validating that
> file, and AFAIK (please correct me if I'm wrong) dpkg-source just picks
> up whatever file, no matter the contents.

If the watch file is properly configured, uscan verifies signature.
You should have upstream keyring stored in

   debian/upstream/signing-key.asc

> > Lastly, it's conceivable that we might want to take an already-armored
> > .asc, and "launder" the armor, to stabilize it (e.g. stripping
> > non-cryptographically-relevant comments, other weird OpenPGP packets,
> > etc, which could all be stuffed into the detached signature).
> 
> I'd love if something did this for me, pretty much like I'd love
> something like that does a pretty output to debian/upstream/signing-key
> like
> https://sources.debian.net/src/inkscape/0.92.2-1/debian/upstream/signing-key.asc/
> (that's
> https://anonscm.debian.org/git/reproducible/misc.git/tree/dump-gpg-keys.sh)
> 
> IOW: Guillem: I second merging that sig→asc converter into dpkg-source!
> :)

1. There are different ways of signature
   * files used
 * detached signature   gpg -sb   (easy)
 * non-detached signature   gpg -s(No answer)
   * format used
 * binary (.gpg, ...) (easy but who convert)
 * ascii  (.asc)  (easy)

2. What to do if upstream is repacked.
   * uscan can confirm but where to put the result in case it is
 repacked.
   * If we leave upstream keyring at debian/upstream/signing-key.asc, it
 has no value to the generated Debian packages.  (A new *.asc can be
 added by maintainer but that's its useless since we upload with
 signed *.dsc.  We need to look into debian/copyright to see if this
 is repacked or not.  But people may use different way to repack.
 So it is confusing to have keyring.  There should be clear way to
 identify if it is repackaged or not easily.) 

Does anyone have clear idea on "gpg -s" case for 1 and answer for 2?

These affects how I write uscan.

Osamu

Re: Upstream Tarball Signature Files

[Osamu Aoki]

Hi,

On Fri, Aug 18, 2017 at 12:08:02PM +0200, Guillem Jover wrote:
> Hi!
> 
> On Wed, 2017-08-16 at 00:22:43 -0700, Paul Hardy wrote:
> > On Tue, Aug 8, 2017 at 1:48 AM, Guillem Jover  wrote:
> > > On Mon, 2017-08-07 at 20:26:41 -0700, Paul Hardy wrote:
> > > > Also, where signature files are desired, I think it would be beneficial
> > > > to also accept binary ".sig" files...
> > >
> > > There is no need for that, you can convert from ASCII armored to
> > > binary signatures and the other way around easily. For example to
> > > convert from .sig to .asc you can do the following:
> > >
> > >   $ gpg --output - --enarmor unifont_upper-10.0.05.ttf.sig | \
> > > sed -e 's/ARMORED FILE/SIGNATURE/;/^Comment:/d' > \
> > > unifont_upper-10.0.05.ttf.asc
> > >   ...
> > >
> > > This could be done automatically as part of uscan, so you'd not even
> > > need to do it manually!
> 
> > Would you consider doing this conversion in a separate shell script as part
> > of dpkg-dev (for example, named "sig2asc")?  Then the script could be run
> > from the command line, and uscan also could invoke it.  If you would accept
> > that, I could write a proposed shell script with a man page for you and
> > file them as patches in a bug against dpkg-dev or mail them to you
> > privately.
> > 
> > I am the GNU Project maintainer for Unifont.  I build the GNU upstream
> > version and the Debian version with one higher-level "make" command at the
> > same time.  So I would not use uscan for OpenPGP format conversion; I only
> > use it in my debian/watch file.
> > 
> > With a separate shell script in place, maintainer documentation could be
> > updated to mention it.  After that, wording for a Policy change concerning
> > upstream signatures could be crafted that would refer to that capability.
> 
> Hmmm, I've been thinking about this a bit, and perhaps it would be
> better if dpkg-source auto-converted any .sig binary signature into
> an .asc ASCII armored one when generating the source package (as long
> as there is no pre-existing .asc file).

If uscan/uupdate can off-load this task to dpkg-source, it's great for
me. They are already too much functionalities in them.

Important thing is (as I already changed my mind as I posted) to keep
this signature file format of the source package to be as uniform as
possible.  Tools such as DAK can support this new source file format
addition with least work.

> This has the advantage of not
> requiring devscripts to be installed, preserves compatibility with
> stable dpkg-source and DAK so it can be used right away, and allows
> us to keep using a single signature format. I've got code doing that
> now, which I can merged for 1.19.0, I guess the only possibly
> contentious point is that this might seem like doing too much magic
> from within dpkg-source?

Wherever we make conversion, it's a magic.  We need to get things
simple across system somehow.

No objection from me.

Anyway gnupg is recommends for dpkg-dev (dpkg-source) already.  So if
gnupg is missing, just spit out warning.

Osamu
 

Re: Upstream Tarball Signature Files

[Osamu Aoki]

Hi,

On Mon, Aug 14, 2017 at 10:13:10AM -0700, Russ Allbery wrote:
> Henrique de Moraes Holschuh  writes:
> 
> > We do when the binary sig is small enough to be stored along with the
> > inode, instead of requiring an entire filesystem block (4KiB), and the
> > armored signature is not small enough for that :-( Of course, this
> > really depends a lot on the filesystem, etc.
> 
> I'm not sure what signatures you're looking at.  Maybe ones with lots of
> separate signers?  A typical *.asc file with one signer is about 500
> bytes.
> 
> > May I humbly suggest that, *if* a change is going to be made, we switch
> > to ".sig" (binary) and ".sig.asc" (armored), or .sig.gpg / sig.gpg.asc?
> > As in "let's not overload .asc to mean armored signature, when it only
> > means ASCII text"...
> 
> Note that I'm arguing for no change, just documenting the existing support
> for *.asc upstream signatures.  This will imply that anyone who wants to
> include an upstream signature that's provided in *.sig format will need to
> convert it to *.asc, but that's not a *change*.  That's the current state
> of the archive.

Very good points.  I changed my mind a bit.

Basically, its better to have uniform rules for format so all associated
tools become simple.  Tools like uscan may accept any signature format,
but the tools at the level of dpkg and archive maintenance tools should
be simple.

I like to use *.asc as signature file.  (Uscan may convert)

Also, maybe policy just mandate debian/upstream/signing-key.asc for key
ring.

Osamu

Bug#743532: lintian: when to say: old-fsf-address-in-copyright-file

[Osamu Aoki]

Hi,

On Thu, Apr 03, 2014 at 06:45:25PM +0200, Jakub Wilk wrote:
 * Osamu Aoki os...@debian.org, 2014-04-04, 01:16:
 License: GPL-2.0+ with incorrect FSF address, and with autoconf exception
 
 FWIW, this line does not conform to the copyright format specification.

What is the offending part? GPL-2.0+ or with ...?

GPL-2+ and the SPDX style GPL-2.0+ are equivalent as specified as
For SPDX compatibility, versions with trailing dot-zeroes are
considered to be equivalent to versions without (e.g., 2.0.0 is
considered equal to 2.0 and 2)..

As for with ... part, I am following An exception or clarification to
a license is signalled in plain text, by appending with keywords
exception to the short name.

I wish to fix problem here.  Please let me know the solution.

(As I re-read spec, I realize my MIT license marking needs to be fixed
to use Expat if it is not X style.)

 For me copying license text including some associated disclaimer exactly
 from the original source seems to be the right thing to do.
 
 Indeed. But the main point of old-fsf-address-in-copyright-file is to let
 you know about _upstream_ problem.

Then please use I: instead of W:.  Warning seems excessive when the
maintainer is aware and tracking its status by marking it in here.

 FYI: This debian/copyright is autogenerated here using debmake packaging
 helper script.
 
 If the copyright file was automatically generated, then there's even greater
 change that you didn't notice the problem yourself.

To be clear, only a template of debian/copyright is autogenerated to
save time for maintainer checking the same license text in different
files word-by-word. Maintainer needs to give final touch which I made it
clear in its documentation.

Most of these trouble comes from autotools.  That is why almost no one
bothered to list such problematic files in this debian/copyright and
they evade annoying warnings by treating such files as a part of *.  I
was surprised to see so many autotools derived files had this problem.

By documenting all files properly with the help of program and marking
their problems obvious, next automatic license check run of the source
tree may find it has been fixed upstream too.  Then he can update
debian/copyright.

(Right now debmake only creates the template file only.  It can not verify
existing debian/copyright against updated source tree yet.)

Osamu


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140405143000.GA16053@goofy

Bug#743532: lintian: when to say: old-fsf-address-in-copyright-file

[Osamu Aoki]

Package: lintian
Version: 2.5.22.1
Severity: normal

Please do not make lintian report this warning of
 W: old-fsf-address-in-copyright-file
if the license synopsis line has with incorrect FSF address.

Here is an example. Lintian reports as:
 W: ... old-fsf-address-in-copyright-file
for debian/copyright containing the following. 

Files: m4/intltool.m4
Copyright: 2001 Eazel, Inc.
License: GPL-2.0+ with incorrect FSF address, and with autoconf exception
 This program 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
 (at your option) any later version.
 .
 This program is distributed in the hope that it will be useful, but
 WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 General Public License for more details.
 .
 You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 .
 As a special exception to the GNU General Public License, if you
 distribute this file as part of a program that contains a
 configuration script generated by Autoconf, you may include it under
 the same distribution terms that you use for the rest of that program.
 .
 On Debian systems, the complete text of the GNU General Public License
 Version 2 can be found in `/usr/share/common-licenses/GPL-2'.



For me copying license text including some associated disclaimer
exactly from the original source seems to be the right thing to do.

Also, I clearly mark with incorrect FSF address in the license
synopsis line.

I think lintian should not issue this warning if it is properly
documented in the license synopsis line.

FYI: This debian/copyright is autogenerated here using debmake packaging
helper script.  So with incorrect FSF address is always spelled
exactly the same way.  I am hoping people to use this dh-make alternative
so DEP-5 is easily implemented and -dbg packages are easily made.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.24-5
ii  bzip2  1.0.6-5
ii  diffstat   1.58-1
ii  file   1:5.17-1
ii  gettext0.18.3.2-1
ii  hardening-includes 2.5
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29+b1
ii  libarchive-zip-perl1.37-2
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.36-1
ii  libdpkg-perl   1.17.6
ii  libemail-valid-perl1.192-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-2
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl   0.06~01-2
ii  libtimedate-perl   2.3000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.6-1
ii  patchutils 0.3.2-3
ii  perl [libdigest-sha-perl]  5.18.2-2+b1
ii  t1utils1.37-2

Versions of packages lintian recommends:
ii  libautodie-perl 2.24-1
ii  libperlio-gzip-perl 0.18-2
ii  perl-modules [libautodie-perl]  5.18.2-2

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.17.6
ii  libhtml-parser-perl3.71-1+b1
ii  libtext-template-perl  1.46-1
ii  libyaml-perl   0.84-1
ii  xz-utils   5.1.1alpha+20120614-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140403161651.GA14893@goofy

Bug#733733: wrong complaint about missing python b-d when python*:any is given.

[Osamu Aoki]

Package: lintian
Version: 2.5.21
Followup-For: Bug #733733

lintian is confused by additional :any added to the package name of
dependency check logic.  Please allow additional :any to be added.

Here is my case:

After realizing python3-all is one of the few new M-A:allowed packages,
I put python3-all:any as build dependency for my arch:all package which
does not have any fancy architecture specific bits, lintian started to
complaining as:

E: debmake source: missing-build-dependency-for-dh-addon python3 = python3 | 
python3-all | python3-dev | python3-all-dev
N: 
N:The source package appears to be using a dh addon but doesn't build
N:depend on the package that actually provides it. If it uses it, it must
N:build depend on it.
N:
N:Severity: important, Certainty: possible
N:
N:Check: debhelper, Type: source
N: 
E: debmake source: missing-python-build-dependency
N: 
N:The package appears to use Python as part of its build process in
N:debian/rules but doesn't depend on Python.
N:
N:Normally, packages that use Python as part of the build process should
N:build-depend on one of python, python-all, python-dev, or python-all-dev
N:depending on whether they support multiple versions of Python and
N:whether they're building modules or only using Python as part of the
N:package build process. Packages that depend on a specific version of
N:Python may build-depend on the appropriate pythonX.Y or pythonX.Y-dev
N:package instead.
N:
N:Refer to Debian Policy Manual section 4.2 (Package relationships) for
N:details.
N:
N:Severity: important, Certainty: certain
N:
N:Check: rules, Type: source
N: 

by changing python3-all:any to python3-all stops above false positive 
messages.

Regards,

Osamu

PS: Only python* and cpp packages are the MA:allowed packages.  
You may also check cpp related check logic.  
There is only one package having cpp:any at this moment.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.24-2
ii  bzip2  1.0.6-5
ii  diffstat   1.58-1
ii  file   1:5.14-2
ii  gettext0.18.3.1-2
ii  hardening-includes 2.5
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29+b1
ii  libarchive-zip-perl1.30-7
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.36-1
ii  libdpkg-perl   1.17.5
ii  libemail-valid-perl1.192-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-1+b2
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl   0.06~01-2
ii  libtimedate-perl   2.3000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.5-3
ii  patchutils 0.3.2-3
ii  perl [libdigest-sha-perl]  5.18.2-2
ii  t1utils1.37-2

Versions of packages lintian recommends:
ii  libautodie-perl 2.22-1
ii  libperlio-gzip-perl 0.18-1+b3
ii  perl-modules [libautodie-perl]  5.18.2-2

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.17.5
ii  libhtml-parser-perl3.71-1+b1
ii  libtext-template-perl  1.46-1
ii  libyaml-perl   0.84-1
ii  xz-utils   5.1.1alpha+20120614-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140116123541.GA9473@goofy

Bug#708138: lintian: python-script-but-no-python-dep should accept python3.3

[Osamu Aoki]

On Sat, May 18, 2013 at 03:58:48PM +0200, Jakub Wilk wrote:
 * Jakub Wilk jw...@debian.org, 2013-05-17, 19:05:
 override_dh_auto_install:
  set -ex; for python in $(PYTHON3); do \
  $$python setup.py install \
   --root=debian/debmake\
   --install-layout=deb; \
  done
 
 setup.py install won't overwrite existing files (unless you use
 --force),
 
 Minor correction: it does overwrite existing files if mtime of the
 new file is bigger. (So in fact, which shebang you end up with is
 timing-dependent. See also bug #547510.)

I see.  Thanks.

Osamu


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130518144528.GA20218@goofy.localdomain

Bug#708138: lintian: python-script-but-no-python-dep should accept python3.3

[Osamu Aoki]

Hi,

I am a bit sick today ... but I got around fixing issues in VCS and
build again:

I attach its build log as xz.


debmake_4.0.0-2_amd64.build.xz
Description: Binary data

Bug#708138: lintian: python-script-but-no-python-dep should accept python3.3

[Osamu Aoki]

Hi,

Excuse me, I did not put this to alioth yet.

On Mon, May 13, 2013 at 04:25:59PM +0200, Jakub Wilk wrote:
...
 If you showed me the source package, I'd try to explain why that
 happened. (I tried to use links from Vcs-* fields for the package
 that is in NEW, but they are broken.)

Hmmm...  Architecture: any oh my god.  


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013051411.GA9588@goofy.localdomain

Bug#708138: lintian: python-script-but-no-python-dep should accept python3.3

[Osamu Aoki]

Package: lintian
Version: 2.5.10.4
Severity: normal

This may be somewhat similar to bug#673734.

I had script started as:
#!/usr/bin/python3

The python3 setup.py with dh --with python3 seems to convert this to:
#! /usr/bin/python3.3
(Please note space.)

I guess, it substitute with the current default python version 3.3
chosen by the python3 package.

Anyway, I get lintian ERROR with somewhat strange texts with my 
package debmake in NEW.

For dh --with ..., we should use python2 for python 2 series and python3 for
python 3 series. dh_pysupport or dh_pycentral are history.

I have Depends: python3 in binary and get the following.  This seems to
limit only to python and do not accept python3 variants.

(The same result with version of lintian in testing/sid=2.5.10.5 too)

$ lintian -i debmake_4.0.0-1_amd64.changes 
E: debmake: python-script-but-no-python-dep usr/bin/debmake
N: 
N:Packages with Python scripts should depend on the package python. Those
N:with scripts that specify a specific version of Python must depend on
N:that version of Python (exactly).
N:
N:For example, if a script in the package uses #!/usr/bin/python, the
N:package needs a dependency on python. If a script uses
N:#!/usr/bin/python2.6, the package needs a dependency on python2.6. A
N:dependency on python (= 2.6) is not correct, since later versions of
N:Python may not provide the /usr/bin/python2.6 binary.
N:
N:If you are using debhelper, adding ${python:Depends} to the Depends
N:field and ensuring dh_pysupport or dh_pycentral are run during the build
N:should take care of adding the correct dependency.
N:
N:In some cases a weaker relationship, such as Suggests or Recommends,
N:will be more appropriate.
N:
N:Severity: important, Certainty: certain
N:
N:Check: scripts, Type: binary
N: 

-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.22-8
ii  bzip2  1.0.6-4
ii  diffstat   1.55-3
ii  file   5.11-2
ii  gettext0.18.1.1-9
ii  hardening-includes 2.3
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26+b1
ii  libarchive-zip-perl1.30-6
ii  libc-bin   2.13-38
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdpkg-perl   1.16.10
ii  libemail-valid-perl0.190-1
ii  libipc-run-perl0.92-1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  locales2.13-38
ii  locales-all [locales]  2.13-38
ii  man-db 2.6.3-3
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-21

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.16.10
ii  libhtml-parser-perl3.69-2
pn  libperlio-gzip-perlnone
ii  libtext-template-perl  1.45-2
ii  man-db 2.6.3-3
ii  xz-utils [lzma]5.1.1alpha+20120614-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130513131440.GA20033@goofy.localdomain

Bug#659574: lintian: legally wrong statement: copyright-with-old-dh-make-debian-copyright

[Osamu Aoki]

Hi,

Thanks for your quick response.

In retrospect, my initial bug report may have had some skewed view on
the copyright law since Japan being more like French law on this subject.

I still think that this lintian report is *pedantic* to nitpick on one
requirement and misses other requirements.  Let me make a bit balanced
requests.
 (1) consideration to avoid negative sentence. (see below)
 (2) explicitly mention US being a signatory to the Berne Convention
 (3) change this to priority pedantic.
 (4) add other essential requirements to establish prima facie case

I will touch each points as below:

On Sun, Feb 12, 2012 at 12:49:45PM -0800, Russ Allbery wrote:
 Russ Allbery r...@debian.org writes:
 
  I'm fairly sure (having read the relevant law several times, as well as
  legal analyses of it) that Lintian's statement is correct in US law,
  although possibly poorly phrased.

Although your new text improves a lot, I am not very happy to see is
not considered as a valid way.  

 @@ -264,9 +264,15 @@ Severity: wishlist
  Certainty: certain
  Info: The copyright file contains the incomplete Debian packaging
   copyright boilerplate from older versions of ttdh_make/tt.
 - tt(C)/tt is not considered as a valid way to express the copyright
^
 - ownership.  The word ttCopyright/tt or the © symbol should be used
 - instead or in addition to tt(C)/tt.
 + tt(C)/tt alone is not considered a valid copyright notice in at least
  ^^^
 + some countries.  The word ttCopyright/tt or the © symbol should be
 + used instead or in addition to tt(C)/tt.
 + .

If the new text was not a negative sentence but a simple affirmative
sentence, I am fine.  --- for (1)

For example:
  The use of the word ttCopyright/tt or the © symbol is considered
  to be a part of a valid copyright notice requirement in at least some 
  countries.

Do you know some previous case that the use of (C) alone for copyright
notice caused some problem to establish prima facie case for
infringement?

 + Copyright notices like this are, in any country that's a signatory to the
 + Berne Convention, not required to claim copyright on a work, but their
 + presence may allow claiming additional damages should a copyright case go
 + to court.  If you provide a notice, you may as well provide one that's
 + legally valid.

Since the US law is always the most central issue for Debian, I would
rather see less ambiguous statement by inserting including USA after
Berne Convention.  --- for (2)

Now, let me explain why I think this to be pedantic.  --- for (3)

I know the use of the symbol © (the letter C in a circle), or the word
“Copyright,” or the abbreviation “Copr.” is part of the valid way
stipulated by the 17 USC § 401 - NOTICE OF COPYRIGHT: VISUALLY
PERCEPTIBLE COPIES as (b)(1), but this code involves more than this
(b)(1) part.
  http://www.law.cornell.edu/uscode/text/17/401

Official examples are given as 37 CFR 201.20 - METHODS OF AFFIXATION
AND POSITIONS OF THE COPYRIGHT NOTICE ON VARIOUS TYPES OF WORKS.
  http://www.law.cornell.edu/cfr/text/37/201/20
Most pertinent section is:
|  (g) Works reproduced in machine-readable copies. For works reproduced in
|  machine-readable copies (such as magnetic tapes or disks, punched cards,
|  or the like, from which the work cannot ordinarily be visually perceived
|  except with the aid of a machine or device, 1 each of the following
|  constitute examples of acceptable methods of affixation and position of
|  notice:
|  (1) A notice embodied in the copies in machine-readable form in such a
|  manner that on visually perceptible printouts it appears either with or
|  near the title, or at the end of the work;
|  (2) A notice that is displayed at the user's terminal at sign on;
|  (3) A notice that is continuously on terminal display; or
|  (4) A legible notice reproduced durably, so as to withstand normal use,
|  on a gummed or other label securely affixed to the copies or to a box,
|  reel, cartridge, cassette, or other container used as a permanent
|  receptacle for the copies.

Assuming the packaging related codes and description contents are
copyrightable, I am not sure if simply placing “Copyright” in an obscure
location in this debian/copyright file complies to these requirements.
This is neither
 * appears either with or near the title, or at the end of the work,
 * displayed at the user's terminal at sign on,
 * continuously on terminal display, nor
 * label securely affixed to the copies or to a box.

So why pick only on (C) thing while such withholding essential
requirements to establish prima facie case for infringement?  This is
the reason I consider this lintian check statement to be pedantic.

In this respect, adding following may balances above issue: --- for (4)

 In order to help such court case, it is also recommended to include
 proper copyright notice for each file or make build script print 

Bug#659574: lintian: legally wrong statement: copyright-with-old-dh-make-debian-copyright

[Osamu Aoki]

Package: lintian
Version: 2.5.4
Severity: important
Tags: patch

Summary:

copyright-with-old-dh-make-debian-copyright is giving a legally
incorrect statement to lintian users in very annoying way.  It is best
removed immediately. -p0 patch attached.

Explanation:

copyright-with-old-dh-make-debian-copyright states:

 The copyright file contains the incomplete Debian packaging
 copyright boilerplate from older versions of ttdh_make/tt.
 tt(C)/tt is not considered as a valid way to express the copyright
 ownership.  The word ttCopyright/tt or the © symbol should be used
 instead or in addition to tt(C)/tt.

The fist sentence is correct but second and third sentences are legally
wrong since 1988 even in USA.

In 1988, USA finally joined Berne Convention for the Protection of
Literary and Artistic Works[1] by Berne Convention Implementation Act
of 1988[2].  (Almost all other industrialized nations signed it already
by then.) This shifted the legal framework of copyright from Anglo-Saxon
concept of copyright to the French right of the author (droit
d'auteur) and removed the general requirement for registration of
copyright works and eliminated the mandatory copyright notice. 

Since then, Agreement on Trade-Related Aspects of Intellectual Property
Rights[3], reinforced this situation on copyright to almost all
nations.

The statement of (C) is not considered as a valid way to express the
copyright ownership. is even harmful for Debian if we accept this since
this is a widely used method.

Of course, having this text is a good indication of not being DEP-5
compliant.  But that test is done separately and it is already marked
pedantic.  So there is no point repeating it here.

FYI:

I know that the web page How to use GNU licenses for your own
software[4] states:

 Always use the English word “Copyright”; by international convention,
 this is used worldwide, even for material in other languages. The
 copyright symbol “©” can be included if you wish (and your character set
 supports it), but it's not necessary. There is no legal significance to
 using the three-character sequence “(C)”, although it does no harm.

But even on this web page, there is statement as follows:

 There is no legal requirement to register your copyright with anyone;
 simply distributing the program makes it copyrighted. 

(I have to admit, this GNU web page seems to be influenced by the
pre-1988 Anglo-US legal requirements.)

Also, I wonder if this recommendation is true, why we have the following
in lintian source :-)

  $ grep -r © *|wc -l
  25
  $ grep -r (C) *|wc -l
  203

Regards,

Osamu

 [1] 
http://en.wikipedia.org/wiki/Berne_Convention_for_the_Protection_of_Literary_and_Artistic_Works
 [2] http://en.wikipedia.org/wiki/Berne_Convention_Implementation_Act_of_1988 
 [3] 
http://en.wikipedia.org/wiki/Agreement_on_Trade-Related_Aspects_of_Intellectual_Property_Rights
 [4] http://www.gnu.org/licenses/gpl-howto.html

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

--- copyright-file.orig	2012-02-12 17:30:03.236256560 +0900
+++ copyright-file	2012-02-12 17:31:04.164558703 +0900
@@ -276,10 +276,6 @@
 tag 'copyright-contains-dh_make-todo-boilerplate';
 }
 
-if (m,The\s+Debian\s+packaging\s+is\s+\(C\)\s+\d+,io) {
-tag 'copyright-with-old-dh-make-debian-copyright';
-}
-
 # Bad licenses.
 if (m/The\s+PHP\s+Licen[cs]e,?\s+version\s+2/si) {
 tag 'copyright-refers-to-bad-php-license';
--- copyright-file.desc.orig	2012-02-12 17:22:05.901889604 +0900
+++ copyright-file.desc	2012-02-12 17:30:42.460451081 +0900
@@ -259,15 +259,6 @@
  check the whole source to find additional copyright/license, or that
  you didn't remove that paragraph after having done so.
 
-Tag: copyright-with-old-dh-make-debian-copyright
-Severity: wishlist
-Certainty: certain
-Info: The copyright file contains the incomplete Debian packaging
- copyright boilerplate from older versions of ttdh_make/tt.
- tt(C)/tt is not considered as a valid way to express the copyright
- ownership.  The word ttCopyright/tt or the © symbol should be used
- instead or in addition to tt(C)/tt.
-
 Tag: copyright-refers-to-bad-php-license
 Severity: serious
 Certainty: possible

Bug#613002: lintian: Please convert SGML to DocBook XML

[Osamu Aoki]

Package: lintian
Version: 2.4.3
Severity: wishlist
User: debian-...@lists.debian.org
Usertags: docbook-xml-transition

Please consider to convert document to DocBook XML using debiandoc2dbk
command in the upcoming debiandoc-sgml package in wheezy.  

I think working on this later after the release of Debian 6.0.2 or so will be
good idea.  No rush.

=== New tools ===

New debiandoc-sgml have debiandoc2dbk command and helper scripts.
Please see the following:
 http://wiki.debian.org/DocbookXmlTransition

I can help the conversion chore.

Thanks.

Osamu



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110212062533.gd30...@debian.org

Bug#575661: [checks/manpages] manpage-has-errors for multibyte issue on col must be skipped?

[Osamu Aoki]

tags 575661 moreinfo
thanks

Hi,

It looks like you reopened this bug originally filed by me.

It felt to me this my bug is closed in my environment.  (I must confess I
did not do much test...)

For people wondering, please see the URL:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=55;bug=575661

David, can you clarify what is your problem and why reopend this.

I failed to understand:
| In a sid chroot I can only get a warning from man if the en_US.utf8 is
| not installed (via dpkg-reconfigure locales) in the chroot.

FYI:
The example script printed by lintian needs en_US.utf8.  Lintian is
smart enough to use a bit more elaborate scheme so it does not require
en_US.utf8.  But documenting such details was considered to destruct key
message.  Thus simple command is written as document.

Did lintian really complained?

Did you typed ... man --warnings ... commands in non en_US.utf8.

If it is the latter, please close this reopen since this s user error.

Osamu




-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100724161449.ga5...@debian.org

Bug#575661: lintian: Fix to col command error

[Osamu Aoki]

Package: lintian
Version: 2.3.4
Severity: normal
Tags: patch

Since this test should work in all environment, I think whoever created
this test must have chosen LANG=C with reason.  I am not even sure if
en_US.UTF-8 exists in the test environment.

Then I also realized there are manpages in many old encodings and they
need to be tested by this script.  Testing for the good UTF-8-ness is
not the right choice (although I suggested so in the previous report.)

So the right thing to do is like other exceptions given in the code.

Please apply attached patch to /usr/share/lintian/checks/manpages
(of course in source file as lintian-2.3.4/checks/manpages)

Osamu

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils   2.20.1-5  The GNU assembler, linker and bina
ii  diffstat   1.47-1produces graph of changes introduc
ii  dpkg-dev   1.15.5.6  Debian package development tools
ii  file   5.04-2Determines file type using magic
ii  gettext0.17-10   GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libapt-pkg-perl0.1.24Perl interface to libapt-pkg
ii  libclass-accessor-perl 0.34-1Perl module that automatically gen
ii  libipc-run-perl0.89-1Perl module for running processes
ii  libparse-debianchangel 1.1.1-2   parse Debian changelogs and output
ii  libtimedate-perl   1.2000-1  collection of modules to manipulat
ii  liburi-perl1.54-1module to manipulate and access UR
ii  locales-all [locales]  2.10.2-6  Embedded GNU C Library: Precompile
ii  man-db 2.5.7-2   on-line manual pager
ii  perl [libdigest-sha-pe 5.10.1-11 Larry Wall's Practical Extraction 

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarchnone (no description available)
pn  libtext-template-perl none (no description available)
ii  man-db2.5.7-2on-line manual pager

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/lintian/checks/manpages (from lintian package)i

Yes, I tested my patch :-)
I overrote this file with the fixed file (see attached patch)
--- manpages.orig	2010-04-10 15:30:41.0 +0900
+++ manpages	2010-04-10 15:41:44.0 +0900
@@ -258,6 +258,9 @@
 	next if /^\s*$/;
 	# ignore errors from gzip, will be dealt with at other places
 	next if /^(man|gzip)/;
+	# ignore errors from col since we are forcing LANG=C which is 
+	# known to be incompatible for UTF-8 output generated by -E UTF-8.
+	next if /^col: Invalid or incomplete multibyte or wide character/;
 	# ignore wrapping failures for Asian man pages (groff problem)
 	if ($lang =~ /^(?:ja|ko|zh)/) {
 		next if /warning \[.*\]: cannot adjust line/;

Bug#575661: lintian: Fix to col command error

[Osamu Aoki]

On Sat, Apr 10, 2010 at 08:15:57AM -0700, Russ Allbery wrote:
 Osamu Aoki os...@debian.org writes:
  On Sat, Apr 10, 2010 at 07:43:39AM -0700, Russ Allbery wrote:
 
  My understanding of how man is supposed to work with character
  encodings says that we should not need to be doing things like this.
  I've been hoping Colin would weigh in on this bug, though, since he
  knows way more about what's going on here than I do.
 
  The current check code seemed to run on all manpages with different
  encoding.  So using UTF-8 is not soulution either.
 
 man is supposed to transcode man pages in other encodings to UTF-8 if the
 locale is UTF-8, isn't it?

My mind is melting ...  You are right.  Then LANG=en_US.UTF-8 seems to
be right solution.



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100410153120.gb9...@osamu.debian.net

Bug#575661: lintian: Fix to col command error

[Osamu Aoki]

On Sat, Apr 10, 2010 at 07:43:39AM -0700, Russ Allbery wrote:
 Osamu Aoki os...@debian.org writes:
 
  Since this test should work in all environment, I think whoever created
  this test must have chosen LANG=C with reason.  I am not even sure if
  en_US.UTF-8 exists in the test environment.
 
 Lintian guarantees that en_US.UTF-8 exists.

Thanks fo confirming this.  (Some code looked like so.)
 
  Then I also realized there are manpages in many old encodings and they
  need to be tested by this script.  Testing for the good UTF-8-ness is
  not the right choice (although I suggested so in the previous report.)
 
  So the right thing to do is like other exceptions given in the code.
 
  Please apply attached patch to /usr/share/lintian/checks/manpages
  (of course in source file as lintian-2.3.4/checks/manpages)
 
 My understanding of how man is supposed to work with character encodings
 says that we should not need to be doing things like this.  I've been
 hoping Colin would weigh in on this bug, though, since he knows way more
 about what's going on here than I do.

The current check code seemed to run on all manpages with different
encoding.  So using UTF-8 is not soulution either.




-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100410150924.ga9...@osamu.debian.net

Bug#575661: lintian: manpage-has-errors-from-man Invalid or incomplete multibyte or wide character when OK.

[Osamu Aoki]

Package: lintian
Version: 2.3.4
Severity: normal

I think lintian is wrong in testing encoding issue for manapage.  I have
installed hello-debhelper (2.5-1).  then I downloaded its binary package
hello-debhelper_2.5-1_amd64.deb and extracted to hello.1 into a working
directry.  

In short, instead of using complicated test, it should use iconv for encoding
test.

Let me show this problem.

First hello-debhelper package installed manpage shows OK under both
LANG=C and LANG=en_US.UTF-8.  I tested it with
 $ LANG=C man hello
 $ LANG=en_US.UTF-8 man hello

The only difference is copyright line.  LANG=C shows copuright as (C)
while UTF-8 uses fancy ©.  No problem.

But

$ lintian -i hello-debhelper_2.5-1_amd64.deb 
W: hello-debhelper: manpage-has-errors-from-man usr/share/man/man1/hello.1.gz  
Invalid or incomplete multibyte or wide character
N: 
N:This man page provokes warnings or errors from man.
N:
N:cannot adjust or can't break are trouble with paragraph filling,
N:usually related to long lines. Adjustment can be helped by left
N:justifying, breaks can be helped with hyphenation, see Manipulating
N:Filling and Adjusting and Manipulating Hyphenation in the manual.
N:
N:can't find numbered character usually means latin1 etc in the input,
N:and this warning indicates characters will be missing from the output.
N:You can change to escapes like \[:a] described on the groff_char man
N:page.
N:
N:Other warnings are often formatting typos, like missing quotes around a
N:string argument to .IP. These are likely to result in lost or malformed
N:output. See the groff_man (or groff_mdoc if using mdoc) man page for
N:information on macros.
N:
N:This test uses man's --warnings option to enable groff warnings that
N:catch common mistakes, such as putting . or ' characters at the start of
N:a line when they are intended as literal text rather than groff
N:commands. This can be fixed either by reformatting the paragraph so that
N:these characters are not at the start of a line, or by adding a
N:zero-width space (\) immediately before them.
N:
N:At worst, warning messages can be disabled with the .warn directive, see
N:Debugging in the groff manual.
N:
N:To test this for yourself you can use the following command:
N: LANG=C MANWIDTH=80 man --warnings -E UTF-8 -l manpage-file /dev/null
N:
N:Severity: normal, Certainty: certain
N:
$ LANG=C MANWIDTH=80 man --warnings -E UTF-8 -l hello.1 hello.txt
col: Invalid or incomplete multibyte or wide character
$ iconv -f utf8 -t utf8 hello.1 /dev/null  echo UTF-8 compatible || echo 
non-UTF-8 found
UTF-8 compatible
$ iconv -f ascii -t ascii hello.1 /dev/null  echo ascii compatible || echo 
non-ascii found
ascii compatible

The first test is the one used by lintian.  Second and third test is mine to
check encoding of source code itself.

$ LANG=C   MANWIDTH=80 man --warnings  -l hello.1 hello.c.txt
$ LANG=en_US.UTF-8 MANWIDTH=80 man --warnings -E UTF-8 -l hello.1 hello.u.txt
$ LANG=C   MANWIDTH=80 man --warnings -E UTF-8 -l hello.1 hello.cu.txt
col: Invalid or incomplete multibyte or wide character
$ ls -l hello.*.txt
-rw-rw-r-- 1 osamu osamu 1417 Mar 28 09:21 hello.c.txt
-rw-rw-r-- 1 osamu osamu0 Mar 28 09:53 hello.cu.txt
-rw-rw-r-- 1 osamu osamu 1418 Mar 28 09:21 hello.u.txt
$ diff -u hello.*.txt
--- hello.c.txt 2010-03-28 09:21:07.0 +0900
+++ hello.u.txt 2010-03-28 09:21:26.0 +0900
@@ -32,7 +32,7 @@
General help using GNU software: http://www.gnu.org/gethelp/

 COPYRIGHT
-   Copyright  (C) 2010 Free Software Foundation, Inc.  License GPLv3+: GNU
+   Copyright  ©  2010  Free Software Foundation, Inc.  License GPLv3+: GNU
GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free  to  change  and  redistribute  it.
There is NO WARRANTY, to the extent permitted by law.

The corresponding groff source has \co as in

Copyright \(co 2010 Free Software Foundation, Inc.

This is embedded nroff which is handled OK for both locale.

So the situation is clear.  There is no non-ASCII code in the source of
manpage.  Its manpage can be interpretted proprly with current tool set.

But test used by lintian breaks on groff copyright mark code.

I made hellox.1 in which \co is replaced with UTF-8 ©.  This is real error 
:-)

$ iconv -f ascii -t ascii hellox.1 /dev/null  echo ascii compatible || 
echo non-ascii found
iconv: illegal input sequence at position 828
non-ascii found
$ iconv -f utf8 -t utf8 hellox.1 /dev/null  echo UTF-8 compatible || echo 
non-UTF-8 found
UTF-8 compatible
$ LANG=C   MANWIDTH=80 man --warnings -E UTF-8 -l hellox.1 
hellox.cu.txt
col: Invalid or incomplete multibyte or wide character
$ LANG=en_US.UTF-8 MANWIDTH=80 man --warnings -E UTF-8 -l hellox.1 hellox.u.txt
$ LANG=C   MANWIDTH=80 man --warnings  -l hellox.1 

Re: Bits from the Lintian maintainers

[Osamu Aoki]

Hi,

(I am noty yet subscribed.  Plese CC me)

On Sat, Jan 02, 2010 at 11:34:53AM -0800, Russ Allbery wrote:
 Wow, two volunteers within a day!  That's excellent.  I'm replying to this
 message since it goes into detail on the conversion process and copying
 Osamu Aoki on this message.  I'm not sure how easily the work can be
 divided up -- maybe both of you can work out between each other how to
 split things up?

There are not much work to split the work.  Both I and Martin have
altready done conversion and question is more about how build script
should be shaped.

I think Martin Ågren understood the autoconversion script well and has done
hardwork part of manually touching up converted file.  Thanks.

 Martin Ågren martin.ag...@gmail.com writes:
  2010/1/2 Russ Allbery r...@debian.org:
 
  We're also looking for someone who would like to tackle converting the
  Lintian manual to Docbook instead of DebianDoc-SGML and working on
  updates.  There's quite a bit about Lintian that isn't currently
  documented.  If you're interested, let us know.
 
  I'm interested in helping out with this. Having cloned the git repo
  and looked into the stuff in doc/, I have some initial observations
  and results and some questions to follow:
 
  With at least debiandoc-sgml, docbook-utils, docbook-xsl, and lynx
  installed, the following gives a good start:
 
  $cd doc
  $debiandoc2docbookxml lintian.sgml
 
  In the resulting file lintian.docbookxml, remove three or four lines
  relating to the pretty-much-empty chapter Top. 

This is one script which does auto conversion. (I took oner maintenance
of this package too.)

debiandoc2xml is another and I used it with -1 option.  (I wrote this script.
It did work fairly well but seems to need some manual tweek more.)

  It is now possible to
  execute
  $docbook2html lintian.docbookxml
  and, similarly,
  $docbook2txt lintian.docbookxml
 
 Oh, excellent.  I didn't realize that the conversion could be largely
 automated via debiandoc2docbookxml.

It looks like Top is some bug.  

I guess after xmllint, Martin's work is good to go.

  This gives html and text versions pretty much as in debian/rules. Not
  exactly, though. There are some formatting differences and, more
  importantly, the abstract/copyright/authors information has
  disappeared in the sgml - docbookxml process. Anyway, this could be a
  starting point for a more thorough, manual walk-through. So...
 
 Yes, that makes sense.

Yes.

  Am I correct in assuming doc/lintian.sgml and only that file is what
  is referred to in Russ' call for help above?
 
 That's correct.
 
 Currently, the Lintian manual is quite short.  I'd like to expand it
 considerably to include, for instance, more details about the internal
 workings of Lintian and guidelines for contributors, instructions on how
 to write a check script for people who want to add custom checks for their
 packages, and so on.  But it seemed like a good idea to convert the manual
 format before doing much additional work.

Yes.  Since these scripts are not meant to be 100% bullet proof, they
are working to the level expected :-) Patches are welcome.

  Since the toolchain is different, I'm guessing aesthetically different
  output is ok when comparing pre-conversion rendering with
  post-conversion rendering.  That is, the aim is to convert the
  contents/semantics and leave the differences in the rendered output.
  (Surely there's a reason newer software produces different rendering.
  :) )
 
 Correct.

Martin's way of build will split out too many small html files.  I guess
using some customization by calling xsltproc like Debian reference
(which was taken from d-i manual build script), can produce more
controlled output with different style.

-
xsltproc --nonet --novalid --xinclude   --stringparam root.filename index \
--stringparam base.dir /tmp/buildd/debian-reference-2.38/html/ \
--stringparam html.ext .fr.html \
--stringparam html.stylesheet debian-reference.css \
xslt/style-html.xsl debian-reference.fr.xml
--

  Would it be ok for me to reserve this work for myself, so that
  duplicate work is avoided? Would a couple of weeks be ok? I've got a
  life ;) but could do this on spare hours here and there.
 
 The two of you are the people who have replied, so I think you can divide
 the work up between yourselves however you see fit.  If anyone else also
 volunteers, I'll point them at you (and I'll update the wiki page
 accordingly).

I do not have write access. Martin seems have done good manual work too.
Let Martin commit XML content first please.
 
  Does a final lintian.docbookxml suffice, or would you prefer the result
  of an automated conversion followed by a series of patches? I'd use some
  VCS anyway, but if individual patches are favoured I'll try harder to
  keep them clean. :)
 
 I'm okay either way on that.  Whichever seems to make the most sense.

 The one other

Re: Bits from the Lintian maintainers

[Osamu Aoki]

Hi,

On Fri, Jan 01, 2010 at 08:11:58PM -0800, Russ Allbery wrote:
 We're also looking for someone who would like to tackle converting the
 Lintian manual to Docbook instead of DebianDoc-SGML and working on
 updates.  There's quite a bit about Lintian that isn't currently
 documented.  If you're interested, let us know.

Yes.  I am interested as being DebianDoc-SGML maintainer :-)

Osamu


-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#405840: lintian: build-depends-indep-should-be-build-depends debhelper with version

[Osamu Aoki]

Package: lintian
Version: 1.23.27
Severity: normal

I have:

| Build-Depends-Indep: debhelper (= 4.1.75)

Then lintian gives me:

| W: debiandoc-sgml source: out-of-date-standards-version 3.6.1 (current is 
3.7.2)
| E: debiandoc-sgml source: build-depends-indep-should-be-build-depends 
debhelper
| W: debiandoc-sgml: old-fsf-address-in-copyright-file

I guess check logic should allow version after package name.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)

Versions of packages lintian depends on:
ii  binutils   2.17-3The GNU assembler, linker and bina
ii  diffstat   1.43-2produces graph of changes introduc
ii  dpkg-dev   1.13.25   package building tools for Debian
ii  file   4.17-5Determines file type using magic
ii  gettext0.16.1-1  GNU Internationalization utilities
ii  intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libparse-debianchangel 1.0-1 parse Debian changelogs and output
ii  man-db 2.4.3-5   The on-line manual pager
ii  perl [libdigest-md5-pe 5.8.8-7   Larry Wall's Practical Extraction 

lintian recommends no packages.

-- no debconf information

-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
Osamu Aoki [EMAIL PROTECTED]  Yokohama Japan, GPG-key: A8061F32
 .''`.  Debian Reference: post-installation user's guide for non-developers
 : :' : http://qref.sf.net and http://people.debian.org/~osamu
 `. `'  Our Priorities are Our Users and Free Software --- Social Contract



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#405840: lintian: build-depends-indep-should-be-build-depends debhelper with version

[Osamu Aoki]

severity 405840 wishlist
retitle  405840 lintian: build-depends-indep-should-be-build-depends 
debhelper confusing
thanks

Hi,

On Sat, Jan 06, 2007 at 11:27:01AM -0800, Russ Allbery wrote:
 Osamu Aoki [EMAIL PROTECTED] writes:
 
  Package: lintian
  Version: 1.23.27
  Severity: normal
 
  I have:
 
  | Build-Depends-Indep: debhelper (= 4.1.75)
 
  Then lintian gives me:
 
  | W: debiandoc-sgml source: out-of-date-standards-version 3.6.1 (current is 
  3.7.2)
  | E: debiandoc-sgml source: build-depends-indep-should-be-build-depends 
  debhelper
  ^
Hmmm... I see it is build-dep here.

  | W: debiandoc-sgml: old-fsf-address-in-copyright-file
 
  I guess check logic should allow version after package name.
 
 It does.  You should probably move debhelper to Build-Depends like lintian
 is suggesting.  Try running lintian -i for more information about why this
 is the case, and let me know if, after reading that, you still think the
 message is wrong.

No.  It is correct but somewhat confusing tag.

If it was something-like:

E: clean-target-should-be-satisfied-by-build-depends debhelper

I was not confused by my failing eye sight :-)

Osamu



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#288568: Description field starting check ...

[Osamu Aoki]

Hi, 290505 and (288568)

Now that lintian is quiet on A, An, The, ...   I am curious.

If it is OK by lintian, are we going to change developer-reference's
best practice section accordingly.

( I thought having good consistency is a good idea. I can not speak for
articles but for capitalization, it could have implimented simple
exception list dictionary: GNU X Debian X11 Gnome KDE PERL, PHP, 
Apache, Scheme, Tcl, Tk, Python, Emacs, Ocmel, C, C++, STL, ...)

-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
Osamu Aoki [EMAIL PROTECTED]  Brussels Belgium, GPG-key: A8061F32
 .''`.  Debian Reference: post-installation user's guide for non-developers
 : :' : http://qref.sf.net and http://people.debian.org/~osamu
 `. `'  Our Priorities are Our Users and Free Software --- Social Contract



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]