When packaging an upstream binary for Debian, I get a lintian error as follows:

E: redwax-tool: copyright-file-contains-full-apache-2-license

This is indeed true, the upstream package provides the full text of the Apache license, as it should. According to https://lintian.debian.org/tags/copyright-file-contains-full-apache-2-license.html we get the following terse explanation:

The copyright file /usr/share/doc/pkg/copyright contains the complete text of the Apache 2.0 license. It should refer to the file /usr/share/common-licenses/Apache-2.0 instead.

What is missing are instructions how to achieve this in the debian directory. Further instructions at https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile say "This file must neither be compressed nor be a symbolic link". The debian/copyright file generated by the debmake tooling ends with the following sensible looking text:

#----------------------------------------------------------------------------
# Files marked as NO_LICENSE_TEXT_FOUND may be covered by the following
# license/copyright files.

#----------------------------------------------------------------------------
# License file: COPYING
                                  Apache License
                            Version 2.0, January 2004
                         http://www.apache.org/licenses/ 
 .
    TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 .
[snip]

Can anyone provide an example or some guidance on concrete packaging steps to take to remove this error.

I am running debuild and lintian automatically finds 2 errors that I have with manpage. the project structure after running debuild command looks like this hoseopjeong@hoseopjeong-VirtualBox:~/Documents/HoseopJeong_debian_lab9/debianlaboration9-0.0$ tree . ├── debian │   ├── changelog │   ├── compat │   ├── control │   ├── copyright │   ├── debhelper-build-stamp │   ├── debianlaboration9 │   │   ├── DEBIAN │   │   │   ├── control │   │   │   └── md5sums │   │   └── usr │   │   ├── bin │   │   │   └── electrotest_standalone │   │   └── share │   │   ├── doc │   │   │   └── debianlaboration9 │   │   │   ├── changelog.Debian.gz │   │   │   ├── copyright │   │   │   └── README.Debian │   │   └── man │   │   └── electrotest_standalone.man.gz │   ├── debianlaboration9.debhelper.log │   ├── debianlaboration9.substvars │   ├── files │   ├── patches │   │   └── series │   ├── README.Debian │   ├── rules │   ├── source │   │   ├── format │   │   └── local-options │   └── watch ├── electrotest_standalone ├── electrotest_standalone.man ├── Makefile └── src └── electrotest_standalone.c the makefile which debuild uses looks like this prefix = /usr/local all: electrotest electrotest: ./src/electrotest_standalone.c gcc -o electrotest_standalone ./src/electrotest_standalone.c -lm install:electrotest install -D electrotest_standalone \ $(DESTDIR)$(prefix)/bin/electrotest_standalone mkdir $(DESTDIR)/usr/share mkdir $(DESTDIR)/usr/share/man cp electrotest_standalone.man \ $(DESTDIR)/usr/share/man/ clean: -rm -f electrotest distclean:clean uninstall: -rm -f $(DESTDIR)$(prefix)/bin/electrotest_standalone .PHONY: all install clean distclean uninstall So, as far as I understand a man file must be located inside usr/share/man. That's why I created ushare/man folders manually with Makefile and I can see when I run debuild command, debuild creates those folders and with `cp electrotest_standalone.man \ $(DESTDIR)/usr/share/man/`, debuild also manages to copy that file into man folder that generated by debuild. However, lintian still doesn't like that. When I run debuild, lintian shows Now running lintian... W: debianlaboration9: improbable-bug-number-in-closes 10 E: debianlaboration9: manpage-in-wrong-directory usr/share/man/electrotest_standalone.man.gz W: debianlaboration9: binary-without-manpage usr/bin/electrotest_standalone It says my man file is in wrong place and binary file electrotest_standalone does not have any man page. What am I doing wrong? Currently my man page just has a single sentence NAME: electrotest_standalone

debuild has an option --lintian-opts that allows to pass options to lintian. How can I pass options to lintian from pdebuild?

Lintian description is as below (taken from $ aptitude show lintian on Debian testing ) - Description: Debian package checker Lintian dissects Debian packages and reports bugs and policy violations. It contains automated checks for many aspects of Debian policy as well as some checks for common errors. It uses an archive directory, called laboratory, in which it stores information about the packages it examines. It can keep this information between multiple invocations in order to avoid repeating expensive data-collection operations. This makes it possible to check the complete Debian archive for bugs, in a reasonable time. This package is useful for all people who want to check Debian packages for compliance with Debian policy. Every Debian maintainer should check packages with this tool before uploading them to the archive. Two interesting lines from the description - (emphasis mine) ***It uses an archive directory, called laboratory, in which it stores information about the packages it examines.*** ***Lintian dissects Debian packages and reports bugs and policy violations*** Now when you see an app. being debianized (meaning have the debian directory in the package/application sub-directory, for e.g. from https://github.com/eloaders/I-Nex.git Thie app. has put compat level as 7 ┌─[shirish@debian] - [~/games/I-Nex/debian] - └─[$] cat compat 7 If we just bump the compat level to 9 from 7, will lintian tell me what needs to be fixed to be 9 compliant ?

Lintian tag description: >The Filesystem Hierarchy Standard forbids the installation of new directories in /usr/bin other than /usr/bin/mh. However, all I can find the linked document is >This is the primary directory of executable commands on the system. This *allows* executable commands to go there, but it does not forbid anything. What paragraph doees Lintian refer to? The reason I like to put a subdirectory there is that I have a wrapper script, that the user uses instead of the binary, and I want the wrapper script to work without changes when "installing" the program. In short, the script looks like options=() debug=0 mode="rel" for option in "$@"; do if [ "$option" == "--debug" ]; then debug=1 mode="dbg" else options+=("$option") fi done current_dir=$(dirname "readlink -f "${BASH_SOURCE}"") binary="$current_dir"/__anja_"$mode"_"$arch"/anja if [ $debug -eq 1 ]; then gdb --args "$binary" "${options[@]}" else exec "$binary" "${options[@]}" fi where arch is deduced from /proc/cpuinfo. The build system emits the binary in the directory __anja_"$mode"_"$arch", in the project root directory. Yes, the correct place for the real binaries is /usr/libexec, but then the script must be changed during the installation procedure.

I am looking and using a github repo. which has a debian directory and debian/rules file which can be used to build the package/tool into a debian package. Using lintian I was able to get some warnings which upstream would probably fix in sometime. I heard some cool things about check-all-the-things and while it has more than a handful of dependencies I was able to install it. But while using lintian on a debian package is easy with $lintian somedebianpackage.deb check-all-the-things doesn't have any clear instructions. Even the manpage is somewhat confusing. I do understand that some flags are dangerous, but is there a way to run all the tests on a debian package to try some QA ?

I recently set up a PPA on Launchpad for distributing my web application. Since it's a server-app, I need to put my data into /var/www/html which apparently is not wanted by Lintian ("dir-or-file-in-var-www"). So far, I accomplish the task via a postinst script, which copies the files after installation, but there has to be a more elegant way, isn't there?

I am currently building my own aptitude repository, and in the process of ensuring that all packages pass as many Lintian checks as possible. Currently I am struggling with 'wrong-file-owner-uid-or-gid' (initial information here , more detailed information here ), and am unsure what a suitable number to use for UID and GID is. Currently I am building packages on an AWS Ubuntu machine: $ id ubuntu uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),102(netdev) These are all as default on the machine. The first link provided says: > The set of the allowed, globally allocated IDs consists of the ranges 0-99, 64000-64999 and 65534. Of these ranges, the second link states: >0-99: Globally allocated by the Debian project, the same on every Debian system. These ids will appear in the passwd and group files of all Debian systems, new ids in this range being added automatically as the base-passwd package is updated. >Packages which need a single statically allocated uid or gid should use one of these; their maintainers should ask the base-passwd maintainer for ids. >60000-64999: Globally allocated by the Debian project, but only created on demand. The ids are allocated centrally and statically, but the actual accounts are only created on users' systems on demand. >These ids are for packages which are obscure or which require many statically-allocated ids. These packages should check for and create the accounts in /etc/passwd or /etc/group (using adduser if it has this facility) if necessary. Packages which are likely to require further allocations should have a "hole" left after them in the allocation, to give them room to grow. >65534: User nobody. The corresponding gid refers to the group nogroup. Can somebody help explain how to conform to this Lintian check for Debian packages? Is it as straightforward as changing the user's UID and GID? What is the most appropriate ID number to choose?

I have read https://lintian.debian.org/ but do not understand what that means in simple words. Which are examples of debian policy rules to be violated and detected by lintian?