| === ricab is now known as ricab|lunch | ||
| === ricab|lunch is now known as ricab | ||
| 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 | 15:44 |
|---|---|---|
| ubottu | Launchpad bug 1837905 in horizon (Ubuntu Disco) " [SRU] stein stable releases " [High,Fix committed] | 15:44 |
| 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 | 16:06 |
| 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:14 |
| 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:15 |
| ahasenack | and an amd64 kernel seems to be installed: linux-generic:amd64 is already the newest version (5.3.0.18.21). | 17:16 |
| 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:18 |
| 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:19 |
| 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:20 |
| ahasenack | then a sea of red started | 17:21 |
| ahasenack | maybe the test should use dpkg-architecture | 17:21 |
| 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:22 |
| ahasenack | let me just check if that python platform module has nothing else I could use | 17:23 |
| ahasenack | platform.architecture() maybe | 17:23 |
| cjwatson | Conceivably I guess | 17:24 |
| cjwatson | This all triggers my "probably testing for the wrong thing" reflex though | 17:25 |
| 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:26 |
| cjwatson | Oh, this is in debian/tests/ | 17:27 |
| cjwatson | You should check the dpkg architecture in that case | 17:27 |
| cjwatson | dpkg --print-architecture would be correct | 17:28 |
| cjwatson | AFAIK there is indeed no way to specify that in autopkgtest metadata | 17:28 |
| cjwatson | Though could you not just put libisal2 in the test's Depends? | 17:29 |
| 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:30 |
| 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:35 |
| ahasenack | looks like that skip was introduced in 1.5.0-1ubuntu2 | 17:36 |
| ahasenack | cjwatson: so how to run the test in amd64, if then it needs libisal2? Where would the libisal2 dep be declared? | 17:37 |
| 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:38 |
| 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:39 |
| 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 | 17:41 |
| mwhudson | if you put unavailable depends in debian/tests/control the tests just fail, i think | 20:45 |
| === kfunk_ is now known as kfunk | ||
| === kees__ is now known as kees | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!