[06:54] <doko> coreycb: nova needs the 3.6 fix: http://autopkgtest.ubuntu.com/packages/n/nova/disco/amd64
[10:00] <seb128> tsimonq2, hey, you have SRU in bionic that need verification for a long time, e.g openbox since june or python-phabricator since august, could you get them verified?
[11:48] <ahasenack> do I need to run germinate-update-metapackage in disco, or am I just missing a package from backports perhaps? I'm on bionic: https://pastebin.ubuntu.com/p/ydGWxd4XgY/
[11:48] <ahasenack> that 'update' script is from the ubuntu-meta source package
[11:50] <cjwatson> Either make sure you have at least as new a version of debootstrap as the last person who ran the script (reported in that error message), or you can ignore it by hacking the debootstrap-version file but then it's on you to check the diff with a fine-toothed comb
[11:55] <ahasenack> cosmic is fine then
[12:16] <ahasenack> no, I need disco
[12:16] <ahasenack> let's see if I can get disco yet
[12:19] <cjwatson> ahasenack: I don't see why.   debootstrap | 1.0.108ubuntu1       | cosmic          | source, all
[12:19] <cjwatson> ahasenack: You might need the one from cosmic-proposed in order to get the disco symlink
[12:19] <ahasenack> it complained about missing /usr/share/debootstrap/scripts/disco
[12:19] <ahasenack> I hacked update.cfg to point at disco instead of cosmic
[12:20] <ahasenack> anyway, got a disco image
[12:20] <cjwatson> ahasenack: https://launchpad.net/ubuntu/+source/debootstrap/1.0.108ubuntu1.1
[12:20] <ahasenack> hm, no I didn't get a disco image
[12:20]  * ahasenack looks for his coffee
[13:24] <doko> coreycb, jamespage: please see the autopkg test failures triggered by python-greenlet: nova cinder heat
[13:25] <coreycb> doko: i'll take a look
[14:20] <seb128> rbasak, thx for the bolt review!
[14:23] <rbasak> np!
[14:31] <rbasak> Laney: please could you help with the autopkgtest failures in the glib2.0 SRU to Bionic? There are rather a lot :(
[14:32] <rbasak> (and I think we want to be force-badtesting everything after verifying if we are to ignore them)
[14:34] <smoser> dannf: https://code.launchpad.net/~dannf/cloud-initramfs-tools/+git/cloud-initramfs-tools/+merge/344193
[14:34] <smoser> is that still a problem ?
[14:36] <bdmurray> mpt: Could you comment on bug 1787553? I find the frequency of the livepatch reminder rather odd.
[14:40] <rbasak> xnox: are you planning on sorting the MERGED_USR thing in the debootstrap SRU backports please? The lack of debootstrap support for the distro-info-data development release is what is I think causing sbuild autopkgtests to fail in the stable releases.
[14:41] <bdmurray> rbasak: agreed
[14:46] <rbasak> I wonder if an alternative is to accept it as-is, given that users release upgrading won't get usr-merge we have to support that anyway.
[14:50] <Laney> rbasak: Okey dokey - do you want my assessments here?
[14:55] <rbasak> Laney: I'm not entirely sure. It'd be nice if you could give me an MP for hints to suppress everything, with justifications. Then I suppose my job is to check that they all seem reasonable, and then I can get the report clear.
[14:55] <rbasak> I'm not sure if that's the expected process now or what.
[14:55] <rbasak> (and of course mark verification-failed-* if any failures are genuine; I'm not sure if I've ever actually seen that :-/
[14:58] <Laney> rbasak: Alright. Doing this makes sense if you want to move to using britney to release the SRUs, anyway.
[14:59] <Laney> For the dev. release the release team shoulders much of the burden - I like that for SRUs you're pushing that back to the uploader
[15:00] <Laney> it's mostly "crappy flaky tests" though, because we don't have good mechanisms/incentives to get them fixed
[15:01] <cpaelzer> hi, has anybody experience using the scons build system with python3 ?
[15:01] <rbasak> pushing that back to the uploader> only because it feels like I make no progress on an SRU shift otherwise, which seems particularly inefficient given that there are relatively few SRU team members and any uploader can do it.
[15:02] <rbasak> it's mostly "crappy flaky tests" though> yeah it's frustrating. I'm not convinced that the benefit of dep8 is currently worth the trade-off of developer time trawling through a gazillion failures.
[15:02] <Laney> imagemagick was obviously broken by something that got released into bionic
[15:03] <smoser> rbasak: interested in what you think about https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+merge/358390
[15:04] <smoser> i realize the chicken-and-egg thing, but I feel that the solution there provides a quick way to run tests and pylint that cannot really be provided by tox
[15:06] <smoser> and https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+merge/358413 is really just a upstream policy... if you want tests in the same files or not.  Either way on that one I think that the pytest.cfg change is an improvement.
[15:10] <rbasak> smoser: on tox, I have no particular opinion, though I was going to run it past powersj wearing a QA hat.
[15:11] <rbasak> smoser: on _test.py, I agree and we adopted that policy a while ago - we just hadn't actively moved old tests into that form.
[15:11] <smoser> so the policy is to move to _test.py.
[15:11] <smoser> ok
[15:13] <smoser> wrt tox. i'm ok to wait on a suggestion from powers, but i can't imagine he'd disagree.  For a number of reasons tox just doesn't "fit" here.
[15:14] <smoser> I love tox, and depend on it elsewhere. but it just doesnt fit here.
[15:14] <rbasak> Sure. I'm just consciously inexperienced in this area.
[15:37] <tsimonq2> seb128: Sure, it's on the TODO list.
[15:38] <tsimonq2> What's the rush?
[15:39] <tsimonq2> (It's been sitting there for a bit, what's the sudden urgency?)
[15:39] <seb128> tsimonq2, having SRUs in the proposed queue unverified since june just feels wrong, what if we need to stack another fix on those? also it means a fix that was upload is not reaching users which is a waste
[15:39] <Laney> What urgency?
[15:40] <Laney> You just got pinged, after multiple months - I think that it's fair enough to think you might need a reminder ...
[15:41] <tsimonq2> Fair.
[15:41] <Laney> 👍
[15:42] <tsimonq2> seb128: needing to stack things on top> Lubuntu maintains both packages, and while my name is on the package, *poke* wxl (QA manager in Lubuntu) to verify. :P
[15:43] <tsimonq2> (Phabricator less so, but it's seen very few updates and we use the archive package in prod.)
[15:43] <seb128> tsimonq2, well, that might be a non point, still we often have SRUs that end up sitting in the proposed queue for years not being verified which is just wrong, those are fixes we cared enough to upload so we should care enough as well to have them reaching the users
[15:43] <seb128> tsimonq2, if we don't care about getting them to user why did we bother doing a SRU upload and wasting reviews time?
[15:44] <tsimonq2> Understood.
[15:44] <seb128> thx :)
[15:44] <tsimonq2> Thanks for the reminder.
[15:49] <coreycb> doko: i'm hitting py36 test failures on disco with 'import _cffi_backend as backend'. it's not an issue if python3.6 is going to be dropped from disco but for now the openstack packages auto-detect py3 versions during builds.
[15:54] <seb128> when can we expect disco to really open?
[15:55] <Laney> after perl and python3-defaults I think
[15:57] <tsimonq2> I wanted to get Qt in too but that's a maybe at this point.
[15:58] <seb128> k, I've no idea how far those are so I guess I will just keep waiting for a while :)
[15:59] <Laney> looking quite good AFAICS
[16:00] <seb128> great, because we are already 3 weeks into the cycle
[16:00] <seb128> so would be good to start moving for other things thattoolchain & early transitions :)
[16:00] <seb128> well, as long as SRU team doesn't block my cosmic fixes "because the fix is not in disco" yet it's ok
[16:06] <rbasak> FWIW, I don't think it makes sense to block SRUs on that. As long as an upload is ready somewhere for Disco I'll be satisfied.
[16:18] <seb128> good to know :)
[17:03] <doko> coreycb: you don't have 3.6 extensions anymore
[17:58] <dannf> smoser: yes, still seeing it. and fyi, hit another issue just now when checking it: https://code.launchpad.net/~dannf/cloud-initramfs-tools/+git/cloud-initramfs-tools/+merge/358453
[18:01] <smoser> dannf: i'll upload as soon as archive is open.
[18:03] <smoser> i'll get that one too.
[18:50] <dannf> smoser: thx!
[20:56] <doko> coreycb: heat ftbfs with test failures
[20:57] <coreycb> doko: working on it thanks. it's the py36 unit tests.