Re: Rebuild for packages with entry points?

[Piotr Ożarowski]

[Nikolaus Rath, 2015-12-08]
> Well, my proposal is to just do a mass rebuild. It will be redundant for
> a lot of packages, but computer time is much cheaper than developer time

it's not always true in case of bandwidth price, though
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Bug#798066: Multiarch-renamed python extensions not found during autopkgtest testing

[Antonio Terceiro]

Control:

On Tue, Dec 08, 2015 at 11:25:47PM -0800, Afif Elghraoui wrote:
> Hi, debian-python,
> 
> For Debian Med's python packages that have compiled extensions, I
> noticed that test suites run via autopkgtest fail because the package
> cannot find those extensions, as they've been renamed with the multiarch
> triplet.
> 
> It seems to only be a problem with autopkgtest because I have in one
> case manually installed such a package and successfully ran its test
> suite. I therefore reported #798066 [1] against autopkgtest, but quite
> some time has elapsed since then and I'd like to get this resolved.
> 
> Does anyone know why this might be the case? Autopkgtest for these
> packages is currently not very helpful because there are many spurious
> failures due to this issue. There are more details in my original bug
> report [1].
> 
> Many thanks and regards
> Afif
> 
> 1. http://bugs.debian.org/798066

autopkgtest does not do anything special wrt dependencies, it will
install exactly what you told it to in debian/tests/control (see the
spec¹ for reference), so I doubt this would be a problem with
autopkgtest.

¹ 
http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst

I am therefore closing this bug.

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature