[15:44] <jamespage> sil2100: hey can we get https://bugs.launchpad.net/cloud-archive/+bug/1837905 release now? sahid_  has confirmed testing and tagged inline with process now
[16:06] <sil2100> jamespage: hey! Sure, let me do that once we're done with the eoan candidate images - I expect I can tackle that somewhere tomorrow
[16:06] <jamespage> sil2100: OK - I have some other updates ready for upload once those have cleared proposed
[17:14] <ahasenack> hi guys, I'm tracking down a dep8 failure in eoan and looks like the i386 test actually was run on a x86_64 host (64bits), is that expected?
[17:14] <ahasenack> test log is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/i386/p/python-pyeclib/20191014_092849_53aad@/log.gz
[17:15] <ahasenack> one can see the intention of running on i386, like -image adt/ubuntu-eoan-i386-server
[17:15] <ahasenack> but at the same time we can also see apt fetching release files from amd64
[17:16] <ahasenack> and an amd64 kernel seems to be installed: linux-generic:amd64 is already the newest version (5.3.0.18.21).
[17:18] <sarnold> ahasenack: I believe there's no 32bit x86 kernel on eoan
[17:18] <sarnold> ahasenack: we're still planning on supporting some of the libraries for 32bit x86 use but the intention is to run them on 64 bit amd64 kernels
[17:19] <ahasenack> the python code is calling platform.machine() to check the arch
[17:19] <ahasenack> that seems to be returning x86_64 when the test is supposed to be running on i386
[17:19] <ahasenack> then the test isn't skipped, and fails
[17:20] <ahasenack> yeah, last good run was on i386 "native"
[17:20] <ahasenack> http://autopkgtest.ubuntu.com/packages/p/python-pyeclib/eoan/i386
[17:20] <ahasenack> just checked the test log from there
[17:21] <ahasenack> then a sea of red started
[17:21] <ahasenack> maybe the test should use dpkg-architecture
[17:22] <cjwatson> dpkg --print-architecture if you want a runtime check of the userspace architecture
[17:22] <sarnold> dpkg-dev: /usr/bin/dpkg-architecture
[17:22] <cjwatson> (dpkg-architecture is in dpkg-dev; dpkg --print-architecture doesn't require -dev)
[17:22] <ahasenack> yeah, that seems to work
[17:23] <ahasenack> let me just check if that python platform module has nothing else I could use
[17:23] <ahasenack> platform.architecture() maybe
[17:24] <cjwatson> Conceivably I guess
[17:25] <cjwatson> This all triggers my "probably testing for the wrong thing" reflex though
[17:26] <sarnold> that's an excellent way to describe that feeling I was getting :) thanks
[17:26] <ahasenack> it's a test that is not meant to be run on i386
[17:26] <ahasenack> dep8 doesn't have a way to express that, does it?
[17:27] <cjwatson> Oh, this is in debian/tests/
[17:27] <cjwatson> You should check the dpkg architecture in that case
[17:28] <cjwatson> dpkg --print-architecture would be correct
[17:28] <cjwatson> AFAIK there is indeed no way to specify that in autopkgtest metadata
[17:29] <cjwatson> Though could you not just put libisal2 in the test's Depends?
[17:30] <cjwatson> Not certain but that would be the first thing I'd try
[17:30] <cjwatson> That's what the test is purportedly for, so let's stop using proxy properties like the current architecture?
[17:35] <ahasenack> not my package, it just got called out in our daily triage. It's blocking python-six
[17:35] <ahasenack> I never heard of python-pyeclib before today :)
[17:35] <ahasenack> trying to figure out the best way to unblock it
[17:36] <ahasenack> looks like that skip was introduced in 1.5.0-1ubuntu2
[17:37] <ahasenack> cjwatson: so how to run the test in amd64, if then it needs libisal2? Where would the libisal2 dep be declared?
[17:38] <ahasenack> the other half of the tests run on all arches
[17:38] <cjwatson> ahasenack: Depends: in debian/tests/control for the particular tests in question
[17:39] <ahasenack> it is in there, but with the [amd64] flag. You mean it should be there without that flag?
[17:39] <cjwatson> ahasenack: In fact it already seems to have "libisal2 [amd64]" there.  I wonder whether just making that be "libisal2" and letting it be unresolvable on other architectures would help
[17:39] <cjwatson> Maybe
[17:39] <cjwatson> Worth testing (locally)
[17:41] <cjwatson> But failing that, check dpkg --print-architecture since this test really does care about the dpkg arch not the kernel arch
[17:41] <cjwatson> Or even test whether the library exists, ctypes.cdll.LoadLibrary or something
[20:45] <mwhudson> if you put unavailable depends in debian/tests/control the tests just fail, i think