<div dir="ltr"><div dir="ltr">On Tue, 24 Mar 2020 at 15:57, Bryce Harrington <<a href="mailto:bryce.harrington@canonical.com">bryce.harrington@canonical.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 23, 2020 at 09:33:49AM -0700, Bryce Harrington wrote:<br>
> rss-bridge<br>
>   - Not sure why this one is failing its test<br>
<br>
I think mwhudson started looking into this.<br></blockquote><div><br></div><div>Indeed I did. I think the summary is that the test will only pass if the version of php-defaults is the same for build and autopkgtest time[0] (it embeds the output of "phpquery -V" at build time into an example nginx config file which the test then uses). So the rss-bridge currently in release won't pass with php-defaults from proposed, and nor will the rss-bridge in proposed pass with the php-defaults from release. A test of both packages from proposed should work though, and I've just triggered one of those. I won't be around for long enough to see if it worked though -- and I only triggered that on amd64 so if that goes green we know what we need to do for other architectures.</div><div><br></div><div>Cheers,</div><div>mwh</div><div>[0] from what I observed trying to reproduce this locally, it seems that when autopkgtest builds a package before testing it, it does not do so with proposed enabled. I guess this isn't surprising when I actually think about it, but it's a difference between production and local testing that hadn't occurred to me before. Next time I guess I'll build with sbuild and test the packages that produced, rather than having autopkgtest do it.</div></div></div>