[00:47] <mwhudson> is it possible to turn off sbuild's log filtering?
[00:47] <mwhudson> ah you can do it in sbuild.conf at least
=== Wryhder is now known as Lucas_Gray
[08:45] <seb128> cpaelzer, hey, thanks for the tpm2-tss review, does it include tpm-udev / bug #1852347 ? it looks like that was split out on the way to address some issues
[08:45] <ubottu> bug 1852347 in tpm-udev (Ubuntu) "[MIR] tpm-udev" [Undecided,New] https://launchpad.net/bugs/1852347
[09:07] <cpaelzer> seb128: that is separate and IIRC on tuesday cyphermox said he is gonna look at that MIR
[09:07] <cpaelzer> seb128: my statement only focsussed on tpm2-tss itself not the further dependency chain
[09:09] <seb128> cpaelzer, k, I though we had fwupd unblocked, seems we are back to square 1 and need a new MIR fully reviewed then :-/
[09:09] <cpaelzer> :-/
[09:10] <seb128> will wait for cyphermox then
[09:10] <cpaelzer> I personally haven't kept track ot the tpm-udev part is that huge or rather big discussion?
[09:11] <seb128> cpaelzer, I've no idea about it, but looks like it was still part of tpm2-tss when the review started, https://bugs.launchpad.net/ubuntu/+source/tpm2-tss/+bug/1841595/comments/6 covers it
[09:11] <ubottu> Launchpad bug 1841595 in tpm2-tss (Ubuntu) "[MIR] tpm2-tss" [Undecided,Fix released]
[09:11] <seb128> and https://launchpad.net/ubuntu/+source/tpm2-tss/2.1.0-4 from eoan has it
[09:11] <seb128> it was only split as a new source in focal
[09:11] <seb128> cpaelzer, which is why I was wondering if the MIR review covered it
[09:12] <seb128> well, hopefully it's a trivial one
[09:17] <cpaelzer> oh it is for sure
[09:17] <cpaelzer> let me help
[09:18] <seb128> thx
[09:25] <cpaelzer> seb128: done, please pick it up
[09:26] <cpaelzer> the process exists to ensure quality and maintainability not to feel inhibited by it - and in that case no new full review cycle was needed
[09:27] <seb128> cpaelzer, great, thanks a lot. I've promoted it now
[09:27] <cpaelzer> yw
[10:02] <sil2100> vicamo: hey! I see two backport-iwlwifi-dkms uploads in the eoan queue - one with version 7906-0ubuntu1.1 and one with 7906-0ubuntu2~19.10.1, which one should I review?
[10:08] <cpaelzer> seb: FYI 1853436
[10:15] <seb128> cpaelzer, right, I just saw it, we will fix that, thx for reporting!
[12:30] <rafaeldtinoco> cpaelzer: is the format you used in mysql-router MIR something MIR team uses ?
[12:30] <rafaeldtinoco> like a checklist for acceptance criteria ?
[12:30] <rafaeldtinoco> (just curious)
=== ricab is now known as ricab|lunch
[12:37] <cpaelzer> rafaeldtinoco: yes
[12:37] <cpaelzer> rafaeldtinoco: if you consider me being the team
[12:37] <cpaelzer> rafaeldtinoco: it is what is docuemented on the wiki pages
[12:37] <rafaeldtinoco> oh you're the only one ?
[12:38] <rafaeldtinoco> =)
[12:38] <cpaelzer> no but everyone has his own style
[12:38] <rafaeldtinoco> gotcha
[12:38] <rafaeldtinoco> i like yours
[12:38] <cpaelzer> I converted the wiki + anything that came up since then - into a template
[12:39] <cpaelzer> rafaeldtinoco: also I like to be transparent in case anybody wonders later on and want to share, therefore https://code.launchpad.net/~paelzer/+git/MIR/+ref/master
[12:40] <cpaelzer> which includes templates for filing as well as for review
[12:40] <rafaeldtinoco> super nice
=== ricab|lunch is now known as ricab
[14:17] <vicamo> sil2100: please do the one with 19.10.1 postfix
[14:52] <coreycb> sil2100: Hi, I think we now have everything verified for nova and cinder in disco-proposed (1849192 and 1833406) so they should be ready to release if you have cycles
[15:54] <bdmurray> seb128: Have you seen bug 1851918?
[15:54] <ubottu> bug 1851918 in python-imaging (Ubuntu) "`hp-check -r` crashes with "AttributeError: module 'PIL.Image' has no attribute 'VERSION'"" [Undecided,Confirmed] https://launchpad.net/bugs/1851918
[16:06] <seb128> bdmurray, I did, I subsribed tkamppeter to it 10 days ago
[16:06] <seb128> tkamppeter, ^ is that on your list of things to investigate?
[16:06] <seb128> bdmurray, do you believe it's important issue by user feedback/stats?
[16:08] <bdmurray> seb128: I gather its a regression so yes
[16:10] <seb128> bdmurray, k, thx, hopefully tkamppeter have some time to have a look soon
[16:55] <tjaalton> how can I get a snap to access a mountpoint under root?
[16:59] <tjaalton> nevermind, installed the deb
[17:00] <ogra> the removable-media interface allows access to /mnt and /media and the mounted bots underneath (assuming the snap packager enable that interface in the snap)
[17:00] <ogra> s/bots/bits/
[17:12] <tjaalton> well, I have a zfs mirror elsewhere, and ~400GB worth of photos for darktable, but I'll just use the deb for now
[17:13] <tjaalton> migrated to a new install, home is on a smaller disk and doesn't hold the photos anymore
[17:14] <ogra> you could just set up a bind mouont to /media
[20:12] <ginggs> xnox: i see your pyfftw upload now FTBFS with 'ResourceWarning: unclosed running multiprocessing pool'
[20:13] <ginggs> I'm seeing the same now in python-xarray autopkgtest, where it passed previously
[20:13] <ginggs> s/the same/very similar/
[20:58] <mwhudson> ah i was just wondering what the secret to getting the python-xarray autopkgtest to pass was
[20:59] <mwhudson> ah ah 0.14.1 is out now
[21:00] <ginggs> mwhudson: well this works https://launchpad.net/~ginggs/+archive/ubuntu/testing/+sourcepub/10752226/+listing-archive-extra
[21:01] <ginggs> but i'm wondering where the problem came from (it wasn't present when I sync'd) and now pyfftw has something similar
[21:02] <mwhudson> ginggs: hmm but i see failures of a different sort with the test triggered by numpy
[21:02] <mwhudson> (and the numpy change is trivial and can't possibly have broken xarray)
[21:03] <mwhudson> maybe that needs the pandas from proposed
[21:03] <ginggs> mwhudson: see http://autopkgtest.ubuntu.com/packages/p/python-xarray/focal/amd64 - the 2019-11-21 18:04:49 UTC test was with all-proposed
[21:05] <ginggs> from what i can see, all tests passed, but autopkgtest failed due to stderr output
[21:11] <mwhudson> ginggs: ah!
[21:11] <mwhudson> ok
[21:11] <mwhudson> gosh this is all such a mess
[21:11] <mwhudson> maybe we can make one big python data science package :(
[21:11] <ginggs> and then RM it?
[21:11] <mwhudson> ha
[21:11] <mwhudson> well at least we'll stop building and testing them on x87 soon
[21:11] <ginggs> \o/
[21:11] <mwhudson> hmm maybe its dask that's using multiprocessing?
[21:11] <mwhudson> does pyfftw use dask?
[21:12] <mwhudson> oorrrrrrrrr maybe this warning is new in python 3.8
[21:12] <mwhudson> ding ding ding we have a winner
[21:12] <ginggs> pyfftw does use dask, or at least can replace dask's fft
[21:12] <mwhudson> yeah i see the string "dask" in the build log
[21:16] <ginggs> mwhudson: i need to sleep, have a good day!
[21:16] <mwhudson> ginggs: i think given that the warning is new in python 3.8, changing the autopkgtests to allow-stderr is probably ok
[21:16] <mwhudson> ginggs: good night!
[21:17] <ginggs> mwhudson: i can upload that quick
[21:18] <mwhudson> ginggs: +1
[21:19] <ginggs> ok, done
[21:25] <mwhudson> uh pandas has a breaks: on skbio but skbio thinks the problem is ok with new scipy which ubuntu has (but debian does not)
[21:25] <mwhudson> this calls for more coffee
[22:30] <mwhudson> hm is there a ppa with gcc 6 (or newer) for xenial?
[22:31] <mwhudson> ah https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test
=== rkta_ is now known as rkta