#644 Issue closed: OBS: debian 7/8 - package creation error¶
Labels: bug
gdha opened issue at 2015-08-21 11:54:¶
We get a failed at OBS for Debian 7 and Debian 8 package build:
[ 89s] + lintian -i /usr/src/packages/rear_1.17.1-0git201508192022_amd64.changes
[ 98s] E: rear source: build-info-in-binary-control-file-section Package rear
[ 98s] N:
[ 98s] N: The control file has a Build-Depends, Build-Depends-Indep,
[ 98s] N: Build-Conflicts, or Build-Conflicts-Indep field in a binary section.
[ 98s] N: These specify source package relationships, and should be in the source
[ 98s] N: section of the control file.
[ 98s] N:
[ 98s] N: Refer to Debian Policy Manual section 5.2 (Source package control files
[ 98s] N: -- debian/control) for details.
[ 98s] N:
[ 98s] N: Severity: serious, Certainty: certain
[ 98s] N:
[ 98s] N: Check: control-file, Type: source
[ 98s] N:
[ 98s] W: rear source: package-depends-on-hardcoded-libc rear depends
[ 98s] N:
[ 98s] N: The given package declares a dependency on libc directly instead of
[ 98s] N: using ${shlibs:Depends} in its debian/control stanza.
[ 98s] N:
[ 98s] N: Severity: normal, Certainty: certain
[ 98s] N:
[ 98s] N: Check: control-file, Type: source
[ 98s] N:
[ 98s] W: rear source: debhelper-but-no-misc-depends rear
[ 98s] N:
[ 98s] N: The source package uses debhelper, but it does not include
[ 98s] N: ${misc:Depends} in the given binary package's debian/control entry. Any
[ 98s] N: debhelper command may add dependencies to ${misc:Depends} that are
[ 98s] N: required for the work that it does, so recommended best practice is to
[ 98s] N: always add ${misc:Depends} to the dependencies of each binary package if
[ 98s] N: debhelper is in use.
[ 98s] N:
[ 98s] N: Refer to the debhelper(7) manual page for details.
[ 98s] N:
[ 98s] N: Severity: normal, Certainty: possible
[ 98s] N:
[ 98s] N: Check: debhelper, Type: source
[ 98s] N:
[ 98s] E: rear source: declares-possibly-conflicting-debhelper-compat-versions rules=5 compat=5
[ 98s] N:
[ 98s] N: The source package declares the debhelper compatibility version both in
[ 98s] N: the debian/compat file and in the debian/rules file. If these ever get
[ 98s] N: out of synchronisation, the package may not build as expected.
[ 98s] N:
[ 98s] N: Refer to the debhelper(7) manual page for details.
[ 98s] N:
[ 98s] N: Severity: important, Certainty: certain
[ 98s] N:
[ 98s] N: Check: debhelper, Type: source
[ 98s] N:
[ 98s] E: rear source: package-uses-debhelper-but-lacks-build-depends
[ 98s] N:
[ 98s] N: If a package uses debhelper, it must declare a Build-Depends on
[ 98s] N: debhelper.
[ 98s] N:
[ 98s] N: Severity: important, Certainty: possible
[ 98s] N:
[ 98s] N: Check: debhelper, Type: source
[ 98s] N:
[ 98s] W: rear source: changelog-should-mention-nmu
[ 98s] N:
[ 98s] N: When you NMU a package, that fact should be mentioned on the first line
[ 98s] N: in the changelog entry. Use the words "NMU" or "Non-maintainer upload"
[ 98s] N: (case insensitive).
[ 98s] N:
[ 98s] N: Maybe you didn't intend this upload to be a NMU, in that case, please
[ 98s] N: doublecheck that the most recent entry in the changelog is byte-for-byte
[ 98s] N: identical to the maintainer or one of the uploaders. If this is a local
[ 98s] N: package (not intended for Debian), you can suppress this warning by
[ 98s] N: putting "local" in the version number or "local package" on the first
[ 98s] N: line of the changelog entry.
[ 98s] N:
[ 98s] N: Refer to Debian Developer's Reference section 5.11.3 (Using the DELAYED/
[ 98s] N: queue) for details.
[ 98s] N:
[ 98s] N: Severity: normal, Certainty: certain
[ 98s] N:
[ 98s] N: Check: nmu, Type: source
[ 98s] N:
[ 98s] W: rear source: source-nmu-has-incorrect-version-number 1.17.1-0git201508192022
[ 98s] N:
[ 98s] N: A source NMU should have a Debian revision of "-x.x" (or "+nmuX" for a
[ 98s] N: native package). This is to prevent stealing version numbers from the
[ 98s] N: maintainer.
[ 98s] N:
[ 98s] N: Maybe you didn't intend this upload to be a NMU, in that case, please
[ 98s] N: doublecheck that the most recent entry in the changelog is byte-for-byte
[ 98s] N: identical to the maintainer or one of the uploaders. If this is a local
[ 98s] N: package (not intended for Debian), you can suppress this warning by
[ 98s] N: putting "local" in the version number or "local package" on the first
[ 98s] N: line of the changelog entry.
[ 98s] N:
[ 98s] N: Refer to Debian Developer's Reference section 5.11.2 (NMUs and
[ 98s] N: debian/changelog) for details.
[ 98s] N:
[ 98s] N: Severity: normal, Certainty: certain
[ 98s] N:
[ 98s] N: Check: nmu, Type: source
[ 98s] N:
[ 98s] W: rear source: debian-rules-sets-DH_COMPAT line 12
[ 98s] N:
[ 98s] N: As of debhelper version 4, the DH_COMPAT environment variable is only to
[ 98s] N: be used for temporarily overriding debian/compat. Any line in
[ 98s] N: debian/rules that sets it globally should be deleted and a separate
[ 98s] N: debian/compat file created if needed.
[ 98s] N:
[ 98s] N: Refer to the debhelper(7) manual page for details.
[ 98s] N:
[ 98s] N: Severity: normal, Certainty: certain
[ 98s] N:
[ 98s] N: Check: rules, Type: source
[ 98s] N:
[ 98s] W: rear source: no-debian-copyright
[ 98s] N:
[ 98s] N: Every package must include the file /usr/share/doc/<pkg>/copyright. A
[ 98s] N: copy of this file should be in debian/copyright in the source package.
[ 98s] N:
[ 98s] N: Refer to Debian Policy Manual section 12.5 (Copyright information) for
[ 98s] N: details.
[ 98s] N:
[ 98s] N: Severity: minor, Certainty: certain
[ 98s] N:
[ 98s] N: Check: source-copyright, Type: source
[ 98s] N:
[ 98s] E: rear source: no-standards-version-field
[ 98s] N:
[ 98s] N: The source package does not have a Standards-Version control field.
[ 98s] N: Please update your package to latest Policy and set this control field
[ 98s] N: appropriately.
[ 98s] N:
[ 98s] N: Refer to Debian Policy Manual section 5.6.11 (Standards-Version) for
[ 98s] N: details.
[ 98s] N:
[ 98s] N: Severity: important, Certainty: certain
[ 98s] N:
[ 98s] N: Check: standards-version, Type: source
[ 98s] N:
[ 98s] E: rear: changelog-file-not-compressed changelog.Debian
[ 98s] N:
[ 98s] N: Changelog files should be compressed using "gzip -9". Even if they start
[ 98s] N: out small, they will become large with time.
[ 98s] N:
[ 98s] N: Refer to Debian Policy Manual section 12.7 (Changelog files) for
[ 98s] N: details.
[ 98s] N:
[ 98s] N: Severity: important, Certainty: certain
[ 98s] N:
[ 98s] N: Check: changelog-file, Type: binary
[ 98s] N:
[ 98s] W: rear: syntax-error-in-debian-changelog line 27 "found start of entry where expected more change data or trailer"
[ 98s] N:
[ 98s] N: While parsing the Debian changelog, a syntax error was found. If you
[ 98s] N: have old changelog entries that don't follow the current syntax but that
[ 98s] N: you want to keep as-is for the historical record, add the line:
[ 98s] N:
[ 98s] N: Old Changelog:
[ 98s] N:
[ 98s] N: with no leading whitespace before the legacy entries. This line and
[ 98s] N: everything after it will be ignored.
[ 98s] N:
[ 98s] N: Refer to Debian Policy Manual section 4.4 (Debian changelog:
[ 98s] N: debian/changelog) for details.
[ 98s] N:
[ 98s] N: Severity: normal, Certainty: possible
[ 98s] N:
[ 98s] N: Check: changelog-file, Type: binary
[ 98s] N:
[ 98s] W: rear: latest-debian-changelog-entry-without-new-version
[ 98s] N:
[ 98s] N: The latest Debian changelog entry has a version number that's either the
[ 98s] N: same or smaller than the version number of the entry before.
[ 98s] N:
[ 98s] N: Severity: normal, Certainty: certain
[ 98s] N:
[ 98s] N: Check: changelog-file, Type: binary
[ 98s] N:
[ 98s] E: rear: no-copyright-file
[ 98s] N:
[ 98s] N: Each binary package has to include a plain file
[ 98s] N: /usr/share/doc/<pkg>/copyright
[ 98s] N:
[ 98s] N: Refer to Debian Policy Manual section 12.5 (Copyright information) for
[ 98s] N: details.
[ 98s] N:
[ 98s] N: Severity: serious, Certainty: certain
[ 98s] N:
[ 98s] N: Check: copyright-file, Type: binary
[ 98s] N:
[ 99s] E: rear: manpage-not-compressed usr/share/man/man8/rear.8
[ 99s] N:
[ 99s] N: Manual pages have to be installed compressed (using "gzip -9").
[ 99s] N:
[ 99s] N: Refer to Debian Policy Manual section 12.1 (Manual pages) for details.
[ 99s] N:
[ 99s] N: Severity: important, Certainty: certain
[ 99s] N:
[ 99s] N: Check: manpages, Type: binary
[ 99s] N:
[ 100s] Use of uninitialized value within @manfile in pattern match (m//) at /usr/share/lintian/checks/manpages line 264, <MANERRS> line 1.
[ 100s] Use of uninitialized value within @manfile in pattern match (m//) at /usr/share/lintian/checks/manpages line 264, <MANERRS> line 1.
[ 100s] W: rear: manpage-has-errors-from-man usr/share/man/man8/rear.8 441: warning [p 5, 7.3i]: can't break line
[ 100s] N:
[ 100s] N: This man page provokes warnings or errors from man.
[ 100s] N:
[ 100s] N: "cannot adjust" or "can't break" are trouble with paragraph filling,
[ 100s] N: usually related to long lines. Adjustment can be helped by left
[ 100s] N: justifying, breaks can be helped with hyphenation, see "Manipulating
[ 100s] N: Filling and Adjusting" and "Manipulating Hyphenation" in the manual.
[ 100s] N:
[ 100s] N: "can't find numbered character" usually means latin1 etc in the input,
[ 100s] N: and this warning indicates characters will be missing from the output.
[ 100s] N: You can change to escapes like \[:a] described on the groff_char man
[ 100s] N: page.
[ 100s] N:
[ 100s] N: Other warnings are often formatting typos, like missing quotes around a
[ 100s] N: string argument to .IP. These are likely to result in lost or malformed
[ 100s] N: output. See the groff_man (or groff_mdoc if using mdoc) man page for
[ 100s] N: information on macros.
[ 100s] N:
[ 100s] N: This test uses man's --warnings option to enable groff warnings that
[ 100s] N: catch common mistakes, such as putting . or ' characters at the start of
[ 100s] N: a line when they are intended as literal text rather than groff
[ 100s] N: commands. This can be fixed either by reformatting the paragraph so that
[ 100s] N: these characters are not at the start of a line, or by adding a
[ 100s] N: zero-width space (\&) immediately before them.
[ 100s] N:
[ 100s] N: At worst, warning messages can be disabled with the .warn directive, see
[ 100s] N: "Debugging" in the groff manual.
[ 100s] N:
[ 100s] N: To test this for yourself you can use the following command:
[ 100s] N: LC_ALL=en_US.UTF-8 MANWIDTH=80 man --warnings -E UTF-8 -l <file> >/dev/null
[ 100s] N:
[ 100s] N: Severity: normal, Certainty: certain
[ 100s] N:
[ 100s] N: Check: manpages, Type: binary
[ 100s] N:
[ 101s] ### WATCHDOG MARKER START ###
[ 104s] [ 69.071390] reboot: Power down
[ 106s] ### WATCHDOG MARKER END ###
gdha commented at 2015-09-22 19:00:¶
FYI OBS works again and I did not change a bit :-/
jsmeix commented at 2015-09-23 07:40:¶
Some background information:
When you did not change your package it happens nevertheless relatively often that all of a sudden your package does no longer build in OBS for this or that repository.
The usual reason is that something else in the repository has changed which lets the build of your package now fail.
Often the root cause is that a change in one package in the repository is somewhat incompatible with other packages in the repository. Usually this gets automagically resolved when the other packages in the repository have been automatically rebuilt so that in the end the whole repository is again in an consistent state. Finally also your package builds again.
Sometimes the root cause is a wrong change in another package in the repository and then it does not get automatically resolved. Instead the wrong change (i.e. bug) must be manually fixed in the other package (by the maintainer of the other package). After the other (now fixed) package was rebuilt, finally also your package builds again.
To find out whether or not the root cause is actually in your package or in another package in the repository you need to inspect the build log in OBS and guess from the reported error message(s) in the build log of your package whether or not it looks like an actual bug in your package.
My personal rule of thumb is: When I did not change my package and all of a sudden my package does no longer build, I assume the root cause is not in my package. Usually I do not even spend any time with inspecting the build log. I simply wait. When the issue does not automagically disappear after some time I have a look at the build log.
Hereby I close this issue.
[Export of Github issue for rear/rear.]