=== ricab is now known as ricab|lunch === ricab|lunch is now known as ricab [15:44] 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 [15:44] Launchpad bug 1837905 in horizon (Ubuntu Disco) " [SRU] stein stable releases " [High,Fix committed] [16:06] 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] sil2100: OK - I have some other updates ready for upload once those have cleared proposed [17:14] 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] 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] one can see the intention of running on i386, like -image adt/ubuntu-eoan-i386-server [17:15] but at the same time we can also see apt fetching release files from amd64 [17:16] and an amd64 kernel seems to be installed: linux-generic:amd64 is already the newest version (5.3.0.18.21). [17:18] ahasenack: I believe there's no 32bit x86 kernel on eoan [17:18] 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] the python code is calling platform.machine() to check the arch [17:19] that seems to be returning x86_64 when the test is supposed to be running on i386 [17:19] then the test isn't skipped, and fails [17:20] yeah, last good run was on i386 "native" [17:20] http://autopkgtest.ubuntu.com/packages/p/python-pyeclib/eoan/i386 [17:20] just checked the test log from there [17:21] then a sea of red started [17:21] maybe the test should use dpkg-architecture [17:22] dpkg --print-architecture if you want a runtime check of the userspace architecture [17:22] dpkg-dev: /usr/bin/dpkg-architecture [17:22] (dpkg-architecture is in dpkg-dev; dpkg --print-architecture doesn't require -dev) [17:22] yeah, that seems to work [17:23] let me just check if that python platform module has nothing else I could use [17:23] platform.architecture() maybe [17:24] Conceivably I guess [17:25] This all triggers my "probably testing for the wrong thing" reflex though [17:26] that's an excellent way to describe that feeling I was getting :) thanks [17:26] it's a test that is not meant to be run on i386 [17:26] dep8 doesn't have a way to express that, does it? [17:27] Oh, this is in debian/tests/ [17:27] You should check the dpkg architecture in that case [17:28] dpkg --print-architecture would be correct [17:28] AFAIK there is indeed no way to specify that in autopkgtest metadata [17:29] Though could you not just put libisal2 in the test's Depends? [17:30] Not certain but that would be the first thing I'd try [17:30] That's what the test is purportedly for, so let's stop using proxy properties like the current architecture? [17:35] not my package, it just got called out in our daily triage. It's blocking python-six [17:35] I never heard of python-pyeclib before today :) [17:35] trying to figure out the best way to unblock it [17:36] looks like that skip was introduced in 1.5.0-1ubuntu2 [17:37] cjwatson: so how to run the test in amd64, if then it needs libisal2? Where would the libisal2 dep be declared? [17:38] the other half of the tests run on all arches [17:38] ahasenack: Depends: in debian/tests/control for the particular tests in question [17:39] it is in there, but with the [amd64] flag. You mean it should be there without that flag? [17:39] 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] Maybe [17:39] Worth testing (locally) [17:41] But failing that, check dpkg --print-architecture since this test really does care about the dpkg arch not the kernel arch [17:41] Or even test whether the library exists, ctypes.cdll.LoadLibrary or something [20:45] if you put unavailable depends in debian/tests/control the tests just fail, i think === kfunk_ is now known as kfunk === kees__ is now known as kees