[01:59] <mwhudson> whyyy does python-twisted in focal-proposed have PyHamcrest in Twisted-18.9.0.egg-info/requires.txt
[02:08] <mwhudson> rbasak, cpaelzer: https://git.launchpad.net/ubuntu/+source/twisted seems amazingly out of date, is that known?
[02:20] <mwhudson> oh turns out in a very roundabout way to be because debian is ahead of ubuntu in some case in py2 removal
[02:20] <mwhudson> sigh
[05:28] <cpaelzer> mwhudson: yeah the repos are not updated, but it is in the whitelist - I'm doing a test import locally to see if this package stumbles over one of the known issues
[05:28] <cpaelzer> it seems it wasn't imported after bionic (neither debian nor ubuntu)
[05:28] <cpaelzer> thanks for the ping mwhudson
[06:48] <cpaelzer> mwhudson: the reimport showed the signature of the issue which let me identify it as bug 1764814
[06:48] <cpaelzer> so it is a known error
[08:13] <mwhudson> cpaelzer: ok, thanks for looking
[08:31] <mitya57> LocutusOfBorg: see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3831/+packages
[08:34] <LocutusOfBorg> perl is almost ready to migrate FYI
[09:48] <tseliot> vorlon, the 435 driver is in bionic NEW (not sure if just the binaries now) LP: #1844126
[09:49] <tjaalton> tseliot: no it isn't?
[09:50] <tseliot> tjaalton, then it needs to be moved to restricted, since it's in multiverse
[09:50] <tseliot> (just checked)
[09:52] <tjaalton> right
[09:58] <tseliot> vorlon, so, the 435 binaries need to be moved from multiverse to restricted in bionic for LP: #1844126. Help would be welcome. Thanks
[09:59] <tjaalton> usually #ubuntu-release is for archive things, someone else might act
[09:59] <tjaalton> since there are other AA's
[11:21] <tjaalton> tseliot, vorlon: moved now by apw
[11:30] <seb128> bdmurray, juliank, bug #1849004 seems a regression from the recent xenial SRU
[12:03] <tseliot> apw, tjaalton  thanks
[12:40] <rafaeldtinoco> morning o/
[14:18] <bdmurray> seb128: noted - thanks
[14:18] <seb128> bdmurray, hey
[14:19] <seb128> bdmurray, did you get anywhere with the retracer problem? It's impacting our ability to tell what issues are impacting users on 19.10 :-/
[14:20] <bdmurray> seb128: Did you hear I'm managing the Foundations team now? I'm a bit busy but hope to dig into it this week. If I got some core files would somebody be interested in trying to retrace them?
[14:22] <sladen> bdmurray: {congrats,commiserations} !
[14:23] <seb128> bdmurray, hey, I did, congrats :) It also mean you get the power to assign the work to somebody else in your team right? :p
[14:23] <bdmurray> sladen: heh
[14:23] <seb128> bdmurray, I would be happy to put it on a bug report on rls-ee-incoming but that's not targetting a package and we don't really have a workflow for those cases :/
[14:24] <seb128> bdmurray, I'm happy to help/do some poking/try to retrace locally if that's useful
[14:26] <bdmurray> seb128: If you could find an "easy" (not too many packages to download) crash that would be a good start.
[14:28] <seb128> bdmurray, https://errors.ubuntu.com/problem/286e2d516e2a4bf784de60a0f3b2ac3281f80b8b , not trivial list but at least it's not a graphical/gtk application
[14:29] <bdmurray> seb128: great thanks!
[14:29] <seb128> np!
[15:30] <vorlon> oSoMoN: kopano-webapp autopkgtests are failing again in focal because they try to install the chromium-browser deb.  "error: snap "chromium" has "install-snap" change in progress" - could you take a look at this? http://autopkgtest.ubuntu.com/packages/k/kopano-webapp/focal/amd64
[15:37] <vorlon> oSoMoN: I suspect that what's happening is the deb postinst finishes while the snap transaction is still in progress, so there's a race
[16:16] <doko> mvo: what is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/c/command-not-found/20191024_083904_d5c23@/log.gz supposed to test? it fails on armhf, but also locally for me ...
[16:21] <infinity> doko: See the amd64 results.  It should be suggesting to install vim/vim-tiny/etc.
[16:21] <infinity> Why it's failing on armhf only is a bit of a mystery.
[16:26] <doko> infinity: would you mind overriding that for now, because a lot of stuff currently fails like that without proposed enabled: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/c/cloudpickle/20191022_091157_d74a8@/log.gz
[16:28] <infinity> doko: That should be re-triggered with python-apt in the triggers, not overridden.
[16:29] <infinity> (cloudpickle, that is... No idea what's up with command-not-found)
[16:29]  * infinity retriggers cloudpickle.
[16:30] <infinity> Oh, I see what you mean.  You want to override c-n-f to migrate python-apt, so it doesn't need explicit triggering.
[16:31] <infinity> Yeah, I could maybe get behind that, if we make a note to figure out WTF is wrong with c-n-f.
[16:31] <doko> yes, exactly
[16:31] <doko> filing a bug report
[16:33] <infinity> doko: Done.
[16:34] <doko> infinity: LP: #1849709
[17:00] <doko> oSoMoN: please could you look at the libreoffice autopkg test failures in focal?
[18:37] <seb128> bdmurray, bug #1848892 was not mentioned in your meeting today despite being high and rls-ee-incoming tagged, was it overlooked or skipped on purpose?
[18:56] <bdmurray> seb128: it was overlooked, thanks for bringing it up
[19:15] <seb128> bdmurray, thx
[19:26] <oSoMoN> marcustomlinson, do_ko pointed out that the libreoffice autopkgtests started failing reliably in focal, something to look into (http://autopkgtest.ubuntu.com/packages/libreoffice/focal/amd64)
[19:26] <oSoMoN> vorlon, I'll look into that
[19:26] <vorlon> oSoMoN: cheers
[19:28] <vorlon> oSoMoN: btw, do you have any feedback on LP: #1849163?  I have yet to find a way to successfully hack around this
[19:28] <oSoMoN> vorlon, not looked at yet, but it's on my to-do list
[19:28] <vorlon> ok ta
[19:31] <oSoMoN> vorlon, re- kopano-webapp, where are you seeing this "error: snap "chromium" has "install-snap" change in progress" ? All I'm seeing is failures because snapd is being killed during installation
[19:32] <oSoMoN> interestingly I've started seeing similar failures on the automated tests for the chromium snap when they are run on arm64, it looks like a recent change in snapd makes it more memory hungry
[19:33] <oSoMoN> I'll start a discussion on the snapcraft forum about this
[19:34] <vorlon> oSoMoN: that particular error message I saw in an arm64 log indeed
[19:34] <oSoMoN> aha!
[19:54] <oSoMoN> vorlon, https://forum.snapcraft.io/t/installing-the-chromium-snap-in-test-environment-results-in-snapd-being-oom-killed/13864
[22:35] <mwhudson> is it possible to get patch(1) to explain _why_ a patch is not applying
[22:37] <sarnold> whenever I've asked that, looking for trailing spaces has usually been the solution
[22:38] <sarnold> I've got this in my ~/.vimrc http://paste.ubuntu.com/p/3zWqK6BcdZ/
[22:38] <sarnold> (yes it's a poor approach to this problem)
[22:39] <mwhudson> in this case it turned out to be emacs and shell in different directories :(
[22:41] <sarnold> probably no amount of vim config would help spot that :)
[23:05] <mwhudson> next stupid question
[23:05] <mwhudson> quilt push; quilt refresh --> patch is unchanged; quilt pop; dpkg-source -b . --> patches don't apply
[23:08] <sarnold> ugh that's even worse. I can't recall now what worked for me in the past, but some combination of quilt push -a, quilt pop -a, and maybe application of this alias alias dq='export QUILT_PATCHES=debian/patches'
[23:08] <mwhudson> ah no this is mismatch between the working directory and the orig
[23:08]  * mwhudson stabs gbp in the face
[23:14] <mwhudson> ok now quilt push is failing which is at least consistent