Bug#678775: lintian: FTBFS: build-dependency not installable: xz-lzma
On 2012-06-24 11:34, Lucas Nussbaum wrote:
> Source: lintian
> Version: 2.5.9
> Severity: serious
> Tags: wheezy sid
> User: debian-qa@lists.debian.org
> Usertags: qa-ftbfs-20120624 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part:
>> ┌──────────────────────────────────────────────────────────────────────────────┐
>> │ Install lintian build dependencies (apt-based resolver) │
>> └──────────────────────────────────────────────────────────────────────────────┘
>>
>> Installing build dependencies
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> Some packages could not be installed. This may mean that you have
>> requested an impossible situation or if you are using the unstable
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>> sbuild-build-depends-lintian-dummy : Depends: xz-lzma but it is not installable
>> E: Unable to correct problems, you have held broken packages.
>> apt-get failed.
>
> The full build log is available from:
> http://people.debian.org/~lucas/logs/2012/06/24/lintian_2.5.9_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
>
>
>
Hi,
"Fun" case. I cannot really reproduce it, but I guess it has to do with
our "xz-lzma | lzma" build depedency. As far as I can tell, xz-lzma is
no longer available[1], but xz-utils now provides lzma[2].
Given dpkg-dev is build essential there is no way (currently) for
xz-utils to be unavailable. I guess it is the "sbuild and virtual
packages" issue (or is it "first alternative only")?
Admittedly we do not explicitly build depend on xz-utils, which smells
like a bug.
~Niels
[1] As of xz-utils/5.1.1alpha+20120614-1.
[2]
Package: xz-utils
[...]
Conflicts: lzma (<< 9.22-1), xz-lzma
Breaks: lzip (<< 1.8~rc2)
Replaces: lzip (<< 1.8~rc2), xz-lzma
Provides: lzma
Reply to: