xine lintian and FTBFS fixes

The Xine library Debian GNU/Linux package lintian warnings were fixed. The bug introduced by the lack of v4l support in the 2.6.38 linux kernel was fixed.

xine hacker survey

A short tour of the Xine project from the perspective of a contributor looking for work.

  • The last news is 2010-07-25
  • The hacks guide is found from the home page
  • There are IRC channels on OFTC and Freenode
  • The mailing list for march and april 2011 show that Andreas Auras is most active
  • A number of xine related mercurial repositories are found on the Debian GNU/Linux mercurial repository. It is unclear which patch queue is used ( http://hg.debian.org/hg/xine-lib/xine-lib-1.2-patch-queue/ and http://hg.debian.org/hg/xine-lib/xine-lib-1.2-patch-queue/.hg/patches/ or http://hg.debian.org/hg/xine-lib/xine-lib-patch-queue/ …)
  • There are a pending bugs in the Debian bug tracker
  • The Alioth project for xine-lib is a placeholder.

fixing lintian warnings

The xine-lib PTS Debian page shows that 13 lintian warnings need attention. The 1.1.19-3 version was downloaded from unstable.
The package uses the source format 3.0 but does not attempt to follow the Patch Tagging Guidelines. The patches can be seen in the patch tracker.
A number of packages missed ” ${misc:Depends}”

N:
N:   The source package uses debhelper, but it does not include
N:   ${misc:Depends} in the given binary package's debian/control entry.
N:   Any debhelper command may add dependencies to ${misc:Depends} that are
N:   required for the work that it does, so recommended best practice is to
N:   always add ${misc:Depends} to the dependencies of each binary package
N:   if debhelper is in use.
N:
N:   Refer to the debhelper(7) manual page for details.
N:
N:   Severity: normal, Certainty: possible
N:

A line in the manual page is long and lintian complains. But the line really is a non-breakable long line, there is no way around it, therefore it was added to the ”debian/overrides/libxine1-doc” override file to silence lintian complaints.

libxine1-doc: manpage-has-errors-from-man usr/share/man/man5/xine.5.gz 220: warning [p 3, 7.0i]: cannot adjust line

The last warning was related to the list of symbols designed to maintain a consistent ABI :

W: libxine1-bin: symbols-file-contains-debian-revision on symbol _x_action_pending@Base and 385 others
N:
N:   Debian revisions should be stripped from versions in symbols files.
N:   Not doing so leads to dependencies unsatisfiable by backports
N:   (1.0-1~bpo << 1.0-1 while 1.0-1~bpo >= 1.0). If the debian revision
N:   can't be stripped because the symbol really appeared between two
N:   specific Debian revisions, you should postfix the version with a
N:   single "~" (example: 1.0-3~ if the symbol appeared in 1.0-3).
N:
N:   Refer to the dpkg-gensymbols(1) manual page and
N:   http://wiki.debian.org/UsingSymbolsFiles for details.
N:
N:   Severity: normal, Certainty: certain
N:

When asked on IRC, ”nthykier” provided a hint on how to fix it:

(12:10:12 PM) loicd: Hi, http://wiki.debian.org/UsingSymbolsFiles suggest that for libxine1-bin the -1 should be removed from all symbols (as shown at http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libxine1-bin_common ). But it does not explain how this could be done. Any suggestion ?
(12:14:57 PM) nthykier: loicd: The last element of each indented line is the version; simply remove the -1 from them and save the file should be enough
(12:15:40 PM) loicd: nthykier: thanks for the tip. I was kind of assuming this file should not be touched by a human hand ;-)
(12:15:40 PM) nthykier: also, if those _x_ symbols are private, they probably should not have been exported
(12:16:32 PM) nthykier: btw, I blindly assumed that the upstream version did not have a -1 in it (most I know of don't)
(12:17:47 PM) loicd: nthykier: xine indeed has no -1 in the version

The source package was then built with ”dpkg-buildpackage -S”

buidling on sid before submission

Before applying the patches an attempt was made to rebuild from sources on a virgin squeeze and on a virgin sid. It failed on sid and succeeded on squeeze. The difference is that

checking linux/videodev.h usability... yes
checking linux/videodev.h presence... yes
checking for linux/videodev.h... yes

is not detected on sid and as a result the following error occurs:

dh_install
dh_install: libxine1-misc-plugins missing files (debian/tmp/usr/lib/xine/plugins/*/xineplug_inp_pvr.so), aborting
make[1]: *** [binary-common] Error 2
make[1]: Leaving directory `/tmp/buildd/xine-lib-1.1.19'

This is because src/input/Makefile.am lines:

if HAVE_V4L
in_v4l = xineplug_inp_v4l.la
in_pvr = xineplug_inp_pvr.la
endif

inhibit xineplug_inp_pvr because configure.ac failed to detect its presence. However, debian/libxine1-misc-plugins.install assumes debian/tmp/usr/lib/xine/plugins/*/xineplug_inp_pvr.so will be created and fails when collecting the package contents.
It turns out that v4l support was dropped in 2.6.38. A FTBFS (Fail To Build From Source) bug was filled to advertise the issue. And a patch was produced to fix it so that it is part of the planned NMU (Non Maintainer Upload).
The final debian/changelog entry is

xine-lib (1.1.19-3.1) unstable; urgency=low

  * NMU.
  * fix lintian warnings
  * remove xineplug_inp_pvr.so from libxine1-misc-plugins.install (Closes: #623595).

 -- Loic Dachary   Thu, 21 Apr 2011 17:49:29 +0200

The package was then built against a virgin sid chroot with

pbuilder --build --buildplace /media/tmp/tmp/build --aptcache /media/tmp/tmp/cache --basetgz /var/cache/pbuilder/sid.tgz xine-lib_1.1.19-3.1.dsc

It was diffed with the previous package using

debdiff xine-lib_1.1.19-3.dsc xine-lib_1.1.19-3.1.dsc

and proposed as a NMU on 623595 bug report.

adjusting the contribution

After a few hours, Darren Salt (aka _ds_ on IRC) suggested that the proposed patch should be split in two and be ready for commit to the mercurial repository.

(06:42:59 PM) _ds_: +Depends: ${misc:Depends}, ${misc:Depends}, …
(06:45:04 PM) _ds_: dachary: series of patches? And ffmpeg_config.h shouldn't be present.
(07:17:36 PM) dachary: _ds_: would you like me to split the patch in two ?
(07:19:11 PM) _ds_: Something like that…
(07:19:21 PM) dachary: I first aimed at fixing the lintian warnings and got carried away by the videodev.h problem. This is not a proper patch, I admit. I would be happy to split it if you want me to.
(07:19:35 PM) dachary: and remove the ffmpeg_config.h diff
(07:20:17 PM) dachary: I was unsure if you preferred me to NMU the patches or if you would like to take care of that yourself. It's not excuse for being somewhat lazy.
(07:20:19 PM) _ds_: Yes… something which can trivially be passed to hg import would be ideal.
_abbenormal _ds_ _julian
(07:20:38 PM) dachary: _ds_: I will work on it right now, thanks for the feedback.
(07:20:56 PM) ***_ds_ should do some upstream stuff, really
(07:21:34 PM) dachary: _ds_: is there a hg upstream I should use to produce ready-to-use diffs ?
(07:22:29 PM) _ds_: See debian/control :-)
(07:24:01 PM) dachary: http://hg.debian.org/hg/xine-lib/pkg/xine-lib-deb indeed :-)

However, it turned out that the repository did not reflect the latest debian package for xine. Nevertheless, the patch was split and appended to the 623595.

(07:27:06 PM) dachary: _ds_: what kind of diff would you prefer ? hg diff ? hg export ? hg bundle ?
(07:28:31 PM) _ds_: Doesn't matter too much
(07:29:28 PM) dachary: _ds_: ok
(07:29:54 PM) dachary: after a clone I see xine-lib (1.1.19-2) unstable; urgency=low at the top of the changelog, are there uncommited changes somewhere ?
(07:32:41 PM) dachary: it's diner time here, I will work on this afterwards. bbl.
(07:41:27 PM) _ds_: siretart: you uploaded -3; you didn't push changes to the repository…
(07:41:43 PM) _ds_: (hmm, not here)
(07:42:40 PM) ***_ds_ notices an unpushed changeset
(07:45:09 PM) CIA-124: xine: Darren Salt * r425:b79db0132a80 xine-lib-deb/.hgtags: Added tag DEBIAN_xine-lib_1.1.19-2 for changeset a5b635273461

One Reply to “xine lintian and FTBFS fixes”

  1. The patch queues are set up to be pulled into xine-lib/.hg/patches or xine-lib-1.2/.hg/patches (depending on which queue). Feel free to test and report on them 🙂

    IRC: we’d intended to move over to OFTC, but it never fully happened: the channel on Freenode kept on being used despite the topic.

    Patches are directly committed to hg, and it’s normal for them to be cherry-picked from upstream. They disappear without further intervention on importing a new upstream release.

    (And I should do a fresh upstream release…)

Comments are closed.