[08:35] <seb128> how often are git ubuntu imports done? like casper 1.403 was uploded almost a week ago and https://git.launchpad.net/ubuntu/+source/casper?h=ubuntu%2Fdevel still has 1.402
[08:35] <seb128> or does that need to be manually updated?
[09:47] <tarzeau> seb128: there's a freeze?
[09:48] <tarzeau> seb128: 19.04 to be released shortly. see http://bootes.ethz.ch/bts/
[09:48] <seb128> tarzeau, that package was accepted, see https://launchpad.net/distros/ubuntu/+source/casper
[09:48] <cjwatson> That doesn't seem hugely relevant in the case of something that's already in the archive though?
[09:49] <cjwatson> Snap
[09:49] <seb128> :)
[09:49] <tarzeau> ah sorry then i have no idea
[10:04] <rbasak> seb128: in a loop, but reliability is still a bit limited. Let me check casper.
[10:06] <seb128> rbasak, thx, is there any log/service where I can check mysefl maybe for next time?
[10:07] <rbasak> seb128: there's a ML you can subscribe to
[10:08] <seb128> rbasak, do you have the name on the list? I'm unsure where to look at
[10:08] <rbasak> Looking for it
[10:11] <rbasak> seb128: looks like the importer hung a week ago :-/
[10:11] <rbasak> I have plans to add a watchdog, but de-prioritised that when it seemed more reliable.
[10:11] <seb128> DOH
[10:11] <rbasak> I will need to bump the priority of that now
[10:12] <seb128> k, well I guess it also means you will look at restarting it now
[10:12] <seb128> thx for poking :)
[10:14] <rbasak> I'm running casper manually for you now, then I'll restart
[10:15] <rbasak> cpaelzer, ahasenack: ^ FYI
[10:15] <rbasak> It had been doing so well!
[10:22] <seb128> rbasak, thank you!
[10:28] <rbasak> It seems to be hanging still. I'm investigating.
[10:47] <rbasak> seb128: this is going to take a while, sorry. The hang is reproducible, and it's during a completely innocuous seeming Launchpad API call.
[10:48] <cjwatson> Even if the API call times out or something it should, well, time out rather than hang
[10:48] <cjwatson> Unless it's retrying indefinitely
[10:59] <rbasak> cjwatson: here's the bottom of the backtrace: https://pastebin.ubuntu.com/p/DkDNbDKN2y/ and call details: https://pastebin.ubuntu.com/p/FzdKNM9bdG/
[11:00] <rbasak> I've seen hangs before that never time out. I never figured out if I was calling something wrong, so I never raised it with you.
[11:00] <rbasak> (hard to reproduce etc)
[11:00] <rbasak> What's odd about this is that we're possibly calling the API repeatedly when we should just cache the result.
[11:01] <rbasak> And I'm pretty sure it's not the first call with these parametrers that is hanging
[11:02] <rbasak> I need to run an errand. Back later.
[11:05] <cjwatson> rbasak: Gotta be a client-side problem, maybe incorrect timeouts being set somewhere or something
[11:51] <rbasak> cjwatson: can you think of any easy way for me to record all API interactions via launchpadlib, and then replay them from outside my application?
[11:51] <rbasak> (replay using launchpadlib again, I mean)
[11:53] <cjwatson> rbasak: I don't have a complete answer, but I'd start with "import httplib2; httplib2.debuglevel = 1" at the top of your program
[11:53] <rbasak> That's useful. Thanks!
[13:24] <cjwatson> didrocks: hi - when there's a comment in a file saying "make sure <thing> remains the last entry", would you mind not adding things after it? :-)  https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=4e86b50e3d368718cd8b0afbc0bc041554bd905d
[13:24] <cjwatson> (fixed now)
[13:25] <didrocks> cjwatson: ah, as it's not the last line, I missed it, I guess it's not possible to add the comment as the last one?
[13:25] <didrocks> (thanks for fixing, I guess this created side-effects?)
[13:25] <cjwatson> The comment could be moved to the end
[13:25] <cjwatson> I'm not sure that would reliably help people not reading it though :)
[13:26] <cjwatson> And yes, it broke source image generation for arcane reasons
[13:26] <didrocks> cjwatson: oh, ok :) TBH, I think comment as last item would have really helped (in my case at least)
[13:26] <cjwatson> I've moved it to the end
[13:26] <didrocks> thx!
[13:27] <cjwatson> thanks for the suggestion
[13:29] <didrocks> (and sorry to have broken it)
[13:29] <didrocks> only tested binary iso build, not source one (not even sure how this can be done locally)
[13:29] <cjwatson> Pretty hard
[13:30] <cjwatson> A slightly more immediate consequence (on the chain of events) was that https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.disco/desktop-minimal-default-languages+build-depends currently exists instead of https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.disco/supported+build-depends
[13:42] <jamespage> hey sil2100 - any chance we can get the bionic part of bug 1818614 accepted into proposed?
[13:47]  * sil2100 looks
[14:14] <jamespage> and....
[14:15] <jamespage> sil2100, bdmurray: any chance we can get the fix for https://bugs.launchpad.net/oslo.cache/+bug/1812935 fastracked to the updates pocket - that's blocking rocky deployments under python 3 right now which is impacting the charm release alongside 19.04
[14:16] <bdmurray> sil2100: do you want me to look at those?
[14:17] <jamespage> and then I see verification has not been done for cosmic - sorry - let me do that now....
[14:18] <sil2100> bdmurray: I'm reviewing the bionic neutron
[14:18] <sil2100> I mean, I'll finish reviewing it once I find the terminal with it
[14:18] <sil2100> It's somewhere there...
[16:14] <Logan> vorlon: I see you going through all of my removal tickets. Appreciate it :)
[16:14] <vorlon> Logan: managed to get the ~ubuntu-archive subscribed bugs list long enough to go through some of them, yeah ;)