Bug#1021368: autopkgtest: quilt patches not applied on arm64, ppc64el, or s390x

[Olek Wojnar]

Hi Paul,

Thanks for the quick reply and the troubleshooting!

On 10/6/22 16:14, Paul Gevers wrote:

Hi Olek,

On 06-10-2022 22:05, Paul Gevers wrote:

On 06-10-2022 21:38, Olek Wojnar wrote:

It's entirely possible that this is also a problem in may package, which is why I have the test suite there in the first place. However, I have not been

able to discover a reason why the tests run correctly on amd64 but fail,


Thanks and happy to provide any additional information if it will help!

exactly as they did before I wrote the patch, on the other architectures.

I notice this in the log, is that the patch you're talking about?

dpkg-source: warning: unexpected end of diff 'src/debian/patches/remove_javac.patch'

debian/patches/add_include_for_limits.patch

No, that patch was just missing a newline, as I recall. The patch in question is:

I have just started the test on one of our workers manually and I can confirm that the patches are all applied.

Pardon my ignorance of the finer points of autopkgtest but is there a way to get more-verbose logging? Are you using the -ddd option? I can't figure out from the CI logs, for example, whether or not quilt successfully applied patches. One reason I thought patches might not be applied was that I never saw quilt being installed in the test bed.

With the following:



I get to test java-1 and after installing quilt I get this:
root@elbrus:/tmp/autopkgtest-lxc.7zdkbsmk/downtmp/build.loA/src# quilt push
File series fully applied, ends at patch debian/patches/remove_skylib.patch

and $(quilt pop -a) confirms I can removal all patches normally.

root@ci-worker-arm64-09:~# /usr/bin/autopkgtest --no-built-binaries --shell-fail --user debci --apt-upgrade --add-apt-release=unstable --pin-packages=unstable=src:bazel-bootstrap bazel-bootstrap -- lxc --sudo --name elbrus autopkgtest-testing-arm64

Ok, well it's good to know that everything applies correctly when done manually!

Is there anything else you want me to run in the testbed of the broken test (please be verbose)?

#include <limits>
#include <stdexcept>



Thanks again!

-Olek

Yes, please. Can you verify that the third_party/ijar/common.h file has the following on lines 24 and 25? Those are the lines that fix the "'numeric_limits' is not a member of 'std'" error. If they are present, that confirms that add_include_for_limits.patch is definitely being applied correctly. But if that's the case, then I'm really stumped as to why we're seeing that failure and only on those architectures...

OpenPGP_signature
Description: OpenPGP digital signature